据我了解,每当我在JPA / Hibernate实体内的Long字段上使用@Id和@GeneratedValue时,我实际上是在使用代理键,考虑到我的非以下方式,我认为这是定义主键的一种非常不错的方法- 使用复合主键的良好经验,其中:
我知道hibernate可以支持这两种类型的PK,但是我以前与有经验的同事聊天时感到很奇怪,他们说复合PK在执行复杂的SQL查询和存储过程时更容易处理。
他们继续说,使用代理密钥在进行联接时会使事情复杂化,并且在几种情况下,使用代理密钥不可能做一些事情。虽然很抱歉,我无法在这里解释细节,因为当他们解释时我还不够清楚。也许我下次再讲更多细节。
我目前正在尝试做一个项目,并且想尝试代理键,因为它不会在表之间重复,因此我们可以更改业务列的值。当需要一些商业价值组合的独特性时,我可以使用类似以下内容的东西:
@Table(name="MY_TABLE", uniqueConstraints={ @UniqueConstraint(columnNames={"FIRST_NAME", "LAST_NAME"}) // name + lastName combination must be unique
但是由于先前有关组合键的讨论,我仍然对此表示怀疑。
您能分享一下这件事的经验吗?谢谢 !
有关任何应用程序的第一条规则是需求会发生变化。期。因此,看起来像是今天PK的理想人选的东西可能根本不是明天的PK。
如果值包含以下特征,则它是PK的良好候选者:
就是说,在现实世界中永久地拥有具有这些特征的任何东西几乎是不可能的。我的意思是,即使某些事物今天是不变的且独特的,也并不意味着它会一直如此。
因此,请尽可能使用代理键。仅对遗留数据库使用自然键。并逃避那些建议自然键比替代(替代)更好的朋友:-)
当然,当然:您可以在数据库中使用约束来强制执行唯一性规则(就像您在示例中所做的那样),如果这是业务规则,则不可能使两个记录共享相同的值。当将来业务逻辑发生变化时,您会很高兴地看到您使用了代理密钥;-)
但是,不要为此而对stackoverflow上的随机家伙信任。阅读维基百科的这两篇文章:
http://en.wikipedia.org/wiki/Surrogate_key
http://en.wikipedia.org/wiki/Natural_key