一尘不染

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

hibernate

据我了解,每当我在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

但是由于先前有关组合键的讨论,我仍然对此表示怀疑。

您能分享一下这件事的经验吗?谢谢 !


阅读 220

收藏
2020-06-20

共1个答案

一尘不染

有关任何应用程序的第一条规则是需求会发生变化。期。因此,看起来像是今天PK的理想人选的东西可能根本不是明天的PK。

如果值包含以下特征,则它是PK的良好候选者:

  1. 这是一成不变的。它永远不会改变。
  2. 独特性 两个记录将永远不会共享相同的ID。

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

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

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

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

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

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

2020-06-20