休眠：复合PK与代理PK中的观点

Question

据我了解，每当我在JPA /
Hibernate实体内的Long字段上使用@Id和@GeneratedValue时，我实际上是在使用代理键，考虑到我的非以下方式，我认为这是定义主键的一种非常不错的方法-
使用复合主键的良好经验，其中：

1. 有不止一种业务-价值-行业组合成为唯一的PK
2. 组合pk值在表详细信息中重复
3. 无法更改该复合PK内的业务价值

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

他们继续说，使用代理密钥在进行联接时会使事情复杂化，并且在几种情况下，使用代理密钥不可能做一些事情。虽然很抱歉，我无法在这里解释细节，因为当他们解释时我还不够清楚。也许我下次再讲更多细节。

我目前正在尝试做一个项目，并且想尝试代理键，因为它不会在表之间重复，因此我们可以更改业务列的值。当需要一些商业价值组合的独特性时，我可以使用类似以下内容的东西：

@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。

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

因此，请尽可能使用代理键。仅对遗留数据库使用自然键。并逃避那些建议自然键比替代（替代）更好的朋友：-)

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

但是，不要为此而对stackoverflow上的随机家伙信任。阅读维基百科的这两篇文章：

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

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