Database 在数据库中表示1:1关系的最佳方式是什么 P>你认为最好的方式来定义1:1关系，比如配偶？

在我的实际数据库中，我有一个人员表，其中一些人员将被归类为与表中的其他人员“联合”（因此，该人员将与原始人员联合）。“联合性”将用于确定每个人的付款

我可以吃点像这样的东西

PERSON
------
Person_ID   (PK)
Name
Phone
Joint_With_ID  (FK)

其中，Joint_With_ID要么为null，要么包含与之关联的记录的Person_ID（该人的记录包含第一人的Person_ID），但我不喜欢故意为null

或者我可以要两张桌子

PERSON                    PERSON_JOIN
------                    -----------
Person_ID   (PK)          Joined_ID       (PK)  
Name                      Person_ID
Phone                     Joined_With_Person_ID 

每对夫妻有两次亲临现场的记录 即

这两种情况都增加了人员1被记录为与人员2联合的可能性，但不存在人员2与人员1联合的记录

我甚至可以在PERSON_JOIN中为每个加入创建一条记录，并在尝试查看一个人是否为joint以及与谁一起加入时使用SQL搜索这两个字段。但那太可怕了

---

所以。。。最好的方式是什么？

夫妻关系通常不是1:1——不是每个人都有配偶。它更像是“0或1”到“0或1”，忽略了一夫多妻和一妻多夫的社会。有些人（但不是所有人）有配偶，那些有配偶的人一次最多有一个配偶。（记录谁是谁的配偶的历史是另一个单独的袋'o'蠕虫。）

因此，您的

PERSON\u JOIN

schema设计远远优于这两者

在我的实际数据库中，我有一个人员表，其中一些人将 被归类为与表中其他人的“联合”（以及 因此，此人将与原始人合并）。这个 “联合性”将用于确定每个人的[原文如此]付款

在SQL数据库中执行此操作的通常方法是对id号施加顺序，并使用检查约束来保证顺序。这假设元组{5，8}与元组{8，5}的意思相同，并且假设一个人不能加入她自己。这里要小心

如果我有“8娶了5，5娶了8”，我会认为这意味着同样的事情。但“8是5的依赖者”与“5是8的依赖者”的含义并不相同

您可能需要一个额外的索引，因为您或多或少需要独立地查询这两个列

create index on person_join (joined_with_person_id);

如果您需要了解人员“5”是否有任何加入人员，您可以

select *
from person_join
where person_id = 5 
   or joined_with_person_id = 5;

---

“每对连接的夫妇都有两个PERSON_JOIN记录”，所以元组{5,8}和{8,5}之间的信息没有差别？我这样问是因为你在谈论支付，在一些应用程序中，这两个元组意味着两种不同的东西。是的，我更喜欢这种方法，但你所说的是正确的，也让我担心——因此我的问题。应用程序需要知道一个人是否与其他人加入，以决定他们是支付联合费用还是个人费用。如果他们是联名的，那么加入的双方将支付联名费用。但是，正如您所说，其中一个元组是多余的，前提是用于查看某人是否加入的sql可以同时考虑这两个字段。我更愿意以某种方式将其构建到模式中，我没有说其中一个元组是多余的。我说过，在某些应用程序中，这两个元组的含义不同。对不起，迈克，我知道你没有这么说。我想我是在质疑，在这种特殊情况下，一个是否是多余的，因为sql“可以”解决它，或者双记录是否是更好的方法，尽管它们都提供了相同的信息是的，这也是我的想法。在这种情况下，不是真正的配偶，这个人或者有或者没有共同的人。如果他们这样做，那么此人也有一个共同的人（另一个人）。我关心的是，SQL负责确保每次插入两条记录，每次删除两条记录，每次更新至少更新2条记录，但最多更新4条记录（如果personA不再与personB联合，但与personC联合，并且personC与personB联合）（并且可能不再与personD联合）这是一个脆弱的SQL！如果您同时执行所有操作，那么它就不必在4条记录处停止：如果您在进行任何更改之前有a=B，C=D，E=F，G=H，然后在a=C，B=E，D=G之后，您仍然需要担心F和H的新分配。为了简化，您需要分两步进行重新分配；对于所有受影响的方，需要一个取消分配步骤（先给出A=B和C=D，后给出A=C，然后取消分配A、B、C和D，然后分配A和C）。这限制了损害。你确定这种关系总是互惠的吗？对配偶来说，是互惠的；对社交网站上的朋友来说，不是互惠的。理解你的数据至关重要。互惠的，是的。商业规则说两个人（而且只有两个人）如果他们是“合作伙伴”且居住在同一地址，则是联合的。此应用程序的用户将决定他们是否是联合的，并将创建“联合的”记录，可能是在第二个人被插入到person表时，也可能是在稍后定义发生“联合”时。（我打算编辑我的评论，以考虑到您突出显示的事件链，但网站不允许这样做。我必须考虑实现您建议的sql，因为person表中的每个人都可能交换！）这似乎是最好的折衷办法，person表中没有空值，联接表中只需要一条记录。用户界面将阻止自联接，因为用户在创建联合记录时只能从所有“其他”人中选择一个人。

  primary key (person_id, joined_with_person_id),

create index on person_join (joined_with_person_id);

select *
from person_join
where person_id = 5 
   or joined_with_person_id = 5;