【发布时间】:2014-10-11 14:42:37
【问题描述】:
您认为哪种方式是定义一对一关系(例如配偶)的最佳方式?
在我的实际数据库中,我有一张人员表,其中有些人将与表中的其他人归类为“联合”(因此该人将与原始人联合)。 “联合”将用于确定每个人的付款。
我可以有类似的东西
PERSON
------
Person_ID (PK)
Name
Phone
Joint_With_ID (FK)
Joint_With_ID 可以为 null 或包含与他们联合的记录的 Person_ID(并且该人的记录包含第一人的 person_ID),但我不喜欢故意为空。
或者我可以有两张桌子
PERSON PERSON_JOIN
------ -----------
Person_ID (PK) Joined_ID (PK)
Name Person_ID
Phone Joined_With_Person_ID
并在 PERSON_JOIN 中为每对联合的夫妇提供两条记录 即
Person_ID Joined_With_Person_ID
5 8
8 5
这两种情况都增加了 person1 被记录为与 person2 联合但不存在 person2 与 person1 联合的记录的可能性。
我什至可以在 PERSON_JOIN 中为每次加入只有一条记录,并在尝试查看一个人是否联合以及与谁在一起时使用 SQL 搜索这两个字段。但这太可怕了!
那么……最好的方法是什么?
【问题讨论】:
-
"并且在 PERSON_JOIN 中为每一对联合的夫妇有两条记录" 那么元组 {5, 8} 和 {8, 5} 之间的信息没有区别吗?我问是因为您在谈论付款,而在某些应用程序中,这两个元组意味着两个不同的东西。
-
是的,我更喜欢这种方法,但你说的是正确的,我也很担心——因此我提出了问题。该应用程序需要知道一个人是否与其他人一起决定他们是否支付联合费用或个人费用。如果他们是联合的,那么加入的双方将支付联合费用。但是,正如您所说,如果用于查看某人是否加入的 sql 可以同时考虑这两个字段,则其中一个元组是多余的。我更愿意以某种方式将其构建到架构中。
-
我没有说其中一个元组是多余的。我说过,在某些应用程序中,这两个元组意味着不同的东西。
-
对不起,迈克,我知道你没有这么说。我想我有点怀疑在这种特殊情况下一个是否是多余的,因为 sql“可以”对其进行排序,或者双记录是否是更好的方法,尽管它们都提供了相同的信息
标签: database relational-database entity-relationship