java - hibernate : Opinions in Composite PK vs Surrogate PK

Question

据我所知，每当我在 JPA/Hibernate 实体内的 Long 字段上使用 @Id 和 @GeneratedValue 时，我实际上是在使用代理键，我认为这是定义主键的一种非常好的方式，考虑到我在使用复合主键方面不太好的经验，其中:

1. 有超过 1 个业务-值(value)-列组合成为唯一的 PK
2. 复合 pk 值在表详细信息中重复
3. 不能改变复合 PK 中的商业值(value)

我知道 hibernate 可以支持这两种类型的 PK，但我之前与有经验的同事聊天时让我感到疑惑，他们说在执行复杂的 SQL 查询和存储过程过程时，复合 PK 更容易处理。

他们继续说，使用代理键会使加入时的事情变得复杂，并且在某些情况下使用代理键无法执行某些操作。虽然我很抱歉我不能在这里解释细节，因为他们解释的时候我不够清楚。也许下次我会提供更多细节。

我目前正在尝试做一个项目，并想尝试代理键，因为它不会跨表重复，而且我们可以更改业务列值。当需要一些业务值(value)组合的唯一性时，我可以使用类似的东西:

@Table(name="MY_TABLE", uniqueConstraints={
    @UniqueConstraint(columnNames={"FIRST_NAME", "LAST_NAME"}) // name + lastName combination must be unique

但由于之前关于组合键的讨论，我仍然有疑问。

您能分享一下您在这件事上的经验吗？谢谢!

Answer 1

关于任何应用程序的第一条规则是需求会发生变化。时期。所以，今天看起来很适合 PK 的东西明天可能根本就不是 PK。

如果一个值包含以下特征，则它是一个很好的 PK 候选者:

1. 它是不可变的。它永远不会改变。
2. 独特性。两条记录永远不会共享相同的 ID。

也就是说，在现实世界中几乎不可能永久拥有具有这些特征的任何东西。我的意思是，即使某些东西在今天是不变的和独特的，也不意味着它会永远如此。

因此，尽可能使用代理键。仅对遗留数据库使用自然键。远离那些建议自然键比代理项更好的 friend (开玩笑):-)

当然:您可以在数据库中使用约束强制执行唯一性规则(就像您在示例中所做的那样)，如果这是业务规则，则两个记录不可能共享相同的值。当 future 业务逻辑发生变化时，你会很高兴看到你使用了代理键;-)

但是不要相信 stackoverflow 上的一个随便的家伙。阅读来自维基百科的这两篇文章:

http://en.wikipedia.org/wiki/Surrogate_key

http://en.wikipedia.org/wiki/Natural_key