5

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

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

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

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

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

你会选择哪个选项？

4

2 回答 2

8

你已经提到了一些我认为你应该避免的做法。我在AppDevelopers 所犯的数据库开发错误（例如独占弧）中写了更多关于此的内容。

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

很多这些数据库设计建模问题都有成熟的解决方案，但这往往不是程序员曾经教过的那种东西。我强烈建议您阅读The Data Model Resource Book, Vol。1：适用于所有企业的通用数据模型库，其中详细介绍了如何对人员和组织进行建模以及许多其他典型问题。

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

于 2009-03-16T21:27:33.910 回答
0

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

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

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

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

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

于 2009-03-16T21:11:00.110 回答