小编Joã*_*iva的帖子

想象一下以下情况：

> A person has a passport.
> A person *owns only* one passport.
> One passport can only *be owned by a single* person. 

这是一对一关系的明显案例。为简单起见，我们假设一个人只有姓名，护照只有国籍。最让我烦恼的是，似乎每个人的做法都不一样。据我所知，可以采取四种策略来映射这种关系：

1. 同一张桌子上的所有东西：

2. 所有者端引用拥有端的外键。

3. 两个表上的主键值相同。

4. 拥有方的外键，顶部有一个唯一键：

• 数字 1 是不言自明的，当实体很小时我没有看到任何问题，但是如果它们有很多字段，我们将有一个巨大的表。
• 数字 2 看起来不错，这是我看到大多数人和框架这样做的方式（例如实体框架、Hibernate），这也是我在学校接受的教学方式。这里的大问题是，由于参照完整性，我们的删除逻辑将被颠倒。我应该可以毫无问题地删除护照，但在这种情况下，我将无法在不删除此人的情况下删除它，这没有任何意义。
• 数字 3 和 4 看起来几乎相同。有了护照一侧的外键，我可以删除护照而不删除人，这是有道理的。如果我移除一个人，我应该必须移除他们的护照。我看到使用选项编号 4 而不是编号 3 或所有其他选项的主要优点是，如果出于任何原因我决定我现在希望用户拥有多本护照，我只需要删除唯一键约束，即与更改两个表中的键相比，非常简单，而且麻烦也少得多。

所以我的问题基本上被简化为以下内容：有了 4 号的这么多优势，为什么人们继续使用其他策略？我最大的把握是使用 ORM，例如 Hibernate，在我看来，它以相反的方式做事。Hibernate 跟踪的关系的拥有方是拥有数据库中外键的关系方。因此，如果我尝试在 Java 中使用 Hibernate 执行此操作，我的关系将被交换。如果我也像它想要的那样在 person 表上包含通行证的外键，它会破坏删除逻辑，就像我之前解释的那样。我的印象是 EF 也以这种方式工作。那么，有了所有这些，为什么人们仍然喜欢“不利”的方法呢？