如何设计对具有附加关系的单个数据库表的循环引用？答案

【问题标题】：How to design a circular reference to a single database table with an added relationship?如何设计对具有附加关系的单个数据库表的循环引用？
【发布时间】：2010-02-28 12:33:47
【问题描述】：

我不确定如何最好地表达这个问题，但基本上我有一个联系人表，而不是做典型的 - 一个联系人引用了一个包含配偶信息的表和一个包含孩子的表，我希望每个人都成为联系人，然后定义这些联系人（兄弟、姐妹、孩子、配偶等）之间的关系。所以联系人将存在于一个表中，但我无法确定如何根据联系人 ID 和关系类型最好地定义关系。任何建议将不胜感激。

【问题讨论】：

标签： sql database database-design data-modeling

【解决方案1】：

`CONTACTS`表

contact_id，PK

`CONTACT_RELATIONSHIP_TYPE_CODE`表

contact_relationship_type_code，PK
description

`CONTACTS_RELATIONS`表

parent_contact_id，pk，CONTACTS 表的外键
child_contact_id，pk，CONTACTS 表的外键
contact_relationship_type_code，CONTACT_RELATIONSHIP_TYPE_CODE 表的外键

如果您发现需要为一对人支持多种关系类型，请将CONTACTS_RELATIONS.contact_relationship_type_code 列添加到复合主键

【讨论】：

小心不要过度规范化这些数据。您可以只拥有一个带有 relationship_code 字段的 contact_relations 表。
我会制作联系人表复合的 PK：parent_contact_id、contact_id、relationship_type_code。这三个应该是独一无二的。此外，桌子上还有一点皱纹。对于兄弟姐妹等对称关系，表中必须有两个条目，否则您的查询必须比必要的更复杂。
@OMG Ponies：如果我正确理解了 CONTACTS_RELATIONS 表，那么 parent_contact_id 是关系中一个人的contact_id，而contact_id 是关系中第二个人的contact_id（在CONTACTS 中）。那是对的吗？另外，为什么要制作这些主键？为什么不将contacts_relations_id 作为PK 和AI，然后对所有三个进行索引？只是好奇。
我的错误。 CONTACTS_RELATIONSHIP 中的 PK 是一个复合键。我误读了解决方案。 @ hal10001，声明主键的主要原因是确保每个主键都是唯一的，并且没有丢失主键的任何部分。如果您为关系声明复合主键，您将获得这些好处。很多设计师总是在每张表的第一列添加一个简单的PK。我的经验表明，这种模式的成本通常比它的价值高，除了实体表。但其他人显然有不同的看法。

【解决方案2】：

这称为自连接，它很常见，也很容易提供您上面提到的功能。看看这个article。

【讨论】：

【解决方案3】：

只需实现一个包含四列的相交表 - 键、联系人 ID #1、联系人 ID #2 和关系。

为什么要这样？因为一个联系人可以有多个关系。

【讨论】：

完美——他们不仅可以有多种关系——而且这些关系可以有自己的属性，比如开始和结束日期（对配偶、姐夫等很重要）、状态等。确保您的设计无需大量工作即可灵活扩展的好方法。请注意，这仅支持二元关系 - 因此，如果您想要其他类型的关系（例如“家庭”），则必须分步进行。

CONTACTS表

CONTACT_RELATIONSHIP_TYPE_CODE表

CONTACTS_RELATIONS表

`CONTACTS`表

`CONTACT_RELATIONSHIP_TYPE_CODE`表

`CONTACTS_RELATIONS`表