我发现这个帖子在某种程度上有助于我的理解，但没有回答我的问题：
SQL: Using NULL values vs. default values
我的问题： 如果我正在创建一个用于存储员工联系信息的模式（在MS Access数据库中），那么最好是为电话号码设置一个表，然后为地址设置一个表，然后为电子邮件地址设置另一个表，或者最好有一个存储所有这些记录的表，但是对于超过一半的记录中的几个字段可能有NULL值？
我想将街道地址的不同元素存储到不同的字段中：对于地址：一个字段用于街道号和名称，一个用于城市，一个用于州，一个对于国家，一个用于邮政编码，还有一个用于地址的任何其他名称（“ATTN：”或类似的），也许更多; 对于电话号码：基本上一个用于名称，一个用于号码; 对于电子邮件：与电话名称和号码基本相同。这会在电话号码的列表中留下许多NULL / Blank值......事实上，我估计可能有70％的记录会有5个或更多的空值，在5,000到10,000个记录的范围内。
我希望能够在单独的列表中以及在组合列表中显示它们，过滤和分组。任何一种结构都可以支持这种情况（通过JOINS / UNIONS和WHERE子句）。就表结构的简单性而言，单个列表看起来很明显 - 一个表比三个或更多表更“整洁”。
答案，我认为，应取决于“存储”潜在的数万个NULL值的效率与索引不同表的效率，并花费时间确保UNION与数据类型对齐并构建各种其他方法来组合已经与SOMEWHAT相关的数据。
我希望我已经清楚地表达了我的想法！我欢迎链接，答案，评论以及问题。
答案 0 :(得分：3)
我会倾向于设计，偏向于每个实体类的单独表。 Person是一个实体类。如果每个人的电话号码不超过一个，您可以将其作为Persons表的属性进行存储。
然而，我通常看到的是希望灵活地为每个人存储多种类型的电话号码：家庭;工作;细胞;传真;将它们存储在单个表（Person_ID，work_phone，home_phone，cell_phone）中会导致设计变得脆弱。当经理告诉您为另一个电话号码类型添加字段时，您将被迫修改表结构，以及使用该表的查询，表单和报告。
我倾向于使用People和PhoneNumbers之间具有一对多关系的单独表格，以便每个电话号码及其类型是PhoneNumbers表中的单独行。该设计避免了单表方法的脆弱性。并且它还避免了你对存储这么多Null值的担忧 - 如果一个Person没有电话号码，你就没有PhoneNumbers中那个Person的行。
但我真的不知道这个建议是否适合你的情况。我认为这取决于您的数据需求的复杂性。
对于单个表的“便利性”，这对我来说似乎无关紧要。访问是关系性的，因此您使用查询将多个表中的相关部分收集到您需要的数据的完整视图中......这可能类似于单个表。如果您故意避免使用这种关系功能，那么将联系信息存储在电子表格中也许不会造成太大损失。
答案 1 :(得分：0)
与商业客户的跟踪信息不同，公司通常对存储员工信息有简单的要求。无需进入计费，运输或办公地址以及各种电话号码。它并不复杂。
对于大多数员工而言，可能不需要Address2字段，但那又如何呢？一旦有人被录用，我认为不需要个人电子邮件地址（将在简历/简历中使用并在面试过程中使用）。应该覆盖2-3个电话号码。
我只是不确定您是否需要使用不同的表添加复杂程度。