数据库结构问题

Question

我目前正在开发一个引用Outlook的Microsoft Business Contact Manager SQL Server数据库加载项的应用程序。 db中的主Contact表有几个子表，它们具有与主表相同的键和少量列;例如，一个包含3列的电子邮件地址表：contactID，EmailAddress和EmailDisplayAs。由于这种方法，您需要使用具有多个外部联接的视图，以查看构成每个联系人记录的所有列。我从未见过这种结构的数据库;至少可以说它看起来很混乱。我很有兴趣看到为什么采用这种方法的评论。

Answer 1

基本上，可选数据有两种通用方法：

1. 将它们包含在tablea的可空（即可选）列中;或
2. 与包含属性逻辑分组的子表使用一对一关系。

我个人认为，除非你处理的是大量的可选属性，否则你应该支持可以为空的列。开销很低，可以忽略不计 - 特别是与大量连接相比。另外，如果您通过一对一关系拥有子表，那么您将再次存储主键（作为子表中的外键），因此可空列的任何存储开销实际上都会减少。

但无论如何，就是这样。

Answer 2

有些原因可能是：

• 大多数查询仅针对初始数据集运行，从而实现更快的查询
• 在初始开发之后添加了附加表，并且ALTER TABLE命令可能非常昂贵
• 最初的意图是建立一种特定类型的联系，但是来自父类型
• 对于给定的父级需要多个子行（尽管这是在索引键的情况下而不是唯一/主键，因此它可能不会飞行）

我见过这样的系统，这样的结构实际上会加快速度，因为较小的查询和较小的关联表保存在逻辑层的内存缓存中。）

Answer 3

这听起来像是对我的基本规范化。联系人是父实体，并且具有构成一对多关系的许多属性。新手设计师有时会将这些存储在同一个表中，您可以获得如phone1，phone2，phone3，email1，email2等列。

规范化允许有效存储信息，并提供一种结构，您可以返回到多属性记录（问题中的视图）。

所以我希望看到一个联系人表（主键为contactId）和一个电话表（使用contactId的外键）和一个电子邮件表（使用contactId的外键）。

如果您不熟悉规范化，主键和外键，我建议您选择像Database Design for Mere Mortals这样的书。

Answer 4

这可能是一个很好的规范化，或者是对更快查询的优化（较小的表宽意味着一次更多的行适合于meory意味着更快的查询），正如其他人所指出的那样。

您仍然必须插入/更新到多个表，但如果您想要一种更简单的方法选择数据，请编写一个使用左外连接的视图从主表中加入所有数据。

Answer 5

具有共享公共密钥的多个表的设计有时允许在不使用NULL标记的情况下省略数据。例如，如果Outlook表中的联系人没有已知的电子邮件地址，则可以从您提到的表中省略一行。

虽然设计可能看起来很麻烦，但是将NULL标记保留在基表之外可以避免在NULLS存在的情况下SQL使用的三个值逻辑所引起的一些混乱。这有时被称为6NF。

如果您需要将它们全部视为由外连接连接的一个表，则可以进行查看。我内心没有这样的观点，我感到有点惊讶。