如何使用来自其他几个表的外键对表建模答案

【问题标题】：How to model tables with foreign keys from several other tables如何使用来自其他几个表的外键对表建模
【发布时间】：2010-10-13 17:19:28
【问题描述】：

我正在尝试创建一个包含两个主要实体的联系人应用程序 - 个人和公司。一个人可以有许多电子邮件、号码和地址。一家公司也可以有许多电子邮件、号码和地址。我正在尝试确定适合这种情况的设计。

选项 #1 - 多个外键
电子邮件、号码和地址将有两列称为 person_id 和 company_id。根据数据所属的实体，一个将为空，另一个将包含一个链接回父级的 id。

选项 #2 - 每个实体每个类型一个表
我复制每个表，因此会有一个 company_addresses 表和一个 person_addresses 表。我会有两倍的表，但这是目前最有意义的解决方案。

选项 #3 - 一个链接表
我创建了一张表 - “链接”。该表将包含四列：source_id、source_entity、dest_id、dest_entity。因此，如果一家公司获得一个新号码，您将有如下一行：1, number, 2, company。

选项 #4 - 多个链接表
我为每种类型的链接（company_address、person_address、company_email、person_email 等）创建了一个表

你会选择哪个选项？

【问题讨论】：

标签： database-design data-modeling

【解决方案1】：

您提到了一些我认为您应该避免的做法。我在Database Development Mistakes Made by AppDevelopers 中写了更多关于此的内容（例如独家弧）。

至于你的问题，我实际上不会选择这些选项。你绊倒的是generic Party model。基本上，您有一个带有子类型（例如 Person 和 Organisation）的 Party 实体。 Contacts 有一个 Party ID 作为外键。通用超类/超实体的使用比这要深刻得多，因为您会发现您也将它用于许多其他事情（例如整个角色概念）。

很多这样的数据库设计建模问题都有成熟的解决方案，但这往往不是程序员曾经教过的那种东西。我强烈推荐阅读The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises 这本书，它更详细地介绍了如何对人员和组织进行建模以及许多其他典型问题。

这里要记住的关键点是你所做的事情以前已经做过了。

【讨论】：

感谢 cletus - 我认为这是以前做过的事情，并且考虑到示例的简单性，我想有一个围绕此的设计实践。我会查看链接并预订。
打败我，这正是我要建议的，但我怀疑写得更好一些。我肯定会查看链接。

【解决方案2】：

选项 #2 或者我会这样做：

您可以创建一个 EntityTable 来定义 Id 和 Entity 类型，然后您可以将您的地址、电子邮件表链接到那个。

然后您创建引用回实体的人员和公司表。换句话说，您的子类实体。

选项 #1 - 我过去曾使用过此选项，但随着事情变得复杂和发展，管理起来可能会让人头疼。

选项 #3 - 您不能使用参照完整性，并且您从节省几个键击来执行选项 #2 所获得的成本将不值得清理不良数据或处理额外的复杂性。

【讨论】：