据我了解，每当我在 JPA/Hibernate 实体内的 Long 字段上使用 @Id 和 @GenerateValue 时，我实际上是在使用代理键，并且我认为这是定义主键的一种非常好的方法，考虑到我的不-使用复合主键的良好体验，其中：
- 超过1个商业价值栏组合成为独特的PK
- 复合 pk 值在表详细信息中重复
- 无法更改该复合 PK 内的业务价值
我知道 hibernate 可以支持这两种类型的 PK，但我之前与经验丰富的同事聊天时留下了疑问，他们说在执行复杂的 SQL 查询和存储过程过程时，复合 PK 更容易处理。
他们继续说，使用代理键会使连接时的事情变得复杂，并且在使用代理键时无法执行某些操作时存在多种情况。虽然很抱歉我无法在这里解释细节，因为他们解释时我不够清楚。也许下次我会提供更多细节。
我目前正在尝试做一个项目，并且想要尝试代理键，因为它不会在表之间重复，并且我们可以更改业务列值。当需要某些业务价值组合的独特性时，我可以使用类似的东西：
@Table(name="MY_TABLE", uniqueConstraints={
@UniqueConstraint(columnNames={"FIRST_NAME", "LAST_NAME"}) // name + lastName combination must be unique
但由于之前关于组合键的讨论，我仍然存有疑问。
您能分享一下您在这方面的经验吗？谢谢 ！
关于任何应用程序的第一条规则是需求会发生变化。时期。因此，今天看起来很适合 PK 的东西明天可能就根本不是 PK 了。
如果某个值包含以下特征，则它是 PK 的良好候选者：
- 它是一成不变的。它永远不会改变。
- 独特性。两条记录永远不会共享相同的 ID。
也就是说，在现实世界中几乎不可能有任何东西永久地具有这些特征。我的意思是，即使某些东西今天是一成不变且独一无二的，但这并不意味着它会永远如此。
因此，尽可能使用代理键。仅对旧数据库使用自然键。远离那些建议自然键比代理更好的朋友（开玩笑）:-)
当然：您可以使用数据库中的约束强制执行唯一性规则（就像在示例中所做的那样），从而使两条记录不可能共享相同的值（如果这是业务规则）。当将来业务逻辑发生变化时，您会很高兴看到您使用了代理键;-)
但不要相信 stackoverflow 上随机的家伙会这么做。阅读维基百科上的这两篇文章：
http://en.wikipedia.org/wiki/Surrogate_key
http://en.wikipedia.org/wiki/Natural_key
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
