休眠：在复合PK对替代PK的意见 [英] Hibernate : Opinions in Composite PK vs Surrogate PK

问题描述

根据我的理解，每当我使用@Id和@GeneratedValue在JPA / Hibernate实体的长字段，我实际上使用代理键，我认为这是一个很好的方式来定义主键考虑我在使用复合主键的不太好的经验，其中：

1. 有超过1个业务值列组合成为独特的PK


2. 复合pk值在表格详细信息中重复出现


3. 不能更改该复合PK内的业务值

我知道hibernate可以支持两种类型的PK，但是我仍然想知道我以前的聊天与经验丰富的同事，他们说复合PK更容易处理执行复杂的SQL查询和存储过程进程。

他们继续说，当使用代理键时，会在做加入时使事情变得复杂，当使用代理键时，有几个条件不可能做一些东西。虽然对不起，我不能解释这里的细节，因为我不够清楚，当他们解释。也许下次我会给更多的细节。

当前试图做一个项目，并想要尝试代理键，因为它不会重复的表，我们可以更改业务列值。当需要某些业务价值组合的唯一性时，我可以使用如下：

  @Table（name =MY_TABLE uniqueConstraints = {
 @UniqueConstraint（columnNames = {FIRST_NAME，LAST_NAME}）// name + lastName组合必须是唯一的
  

但是我仍然怀疑，因为之前有关复合键的讨论。

你能分享你的经验吗？你！

解决方案

任何应用程序的第一个规则是需求变化。

如果PK包含以下特征，则它是PK的好候选：

$ b $

b $ b

也就是说，在现实世界中永远不可能有这些特性。我的意思是，即使某些东西是不可变的和独特的今天，这并不意味着它总是这样。

因此，尽可能使用代理键。仅对于旧数据库使用自然键。并且逃避那些建议自然键比代理（开玩笑）更好的朋友： - ）

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

但不要信任stackoverflow上的随机花花公子为了这。阅读维基百科中的这两篇文章：

http：//en.wikipedia。 org / wiki / Surrogate_key

http：// en。 wikipedia.org/wiki/Natural_key

As i understand it, whenever i use @Id and @GeneratedValue on a Long field inside JPA/Hibernate entity, i'm actually using a surrogate key, and i think this is a very nice way to define a primary key considering my not-so-good experiences in using composite primary keys, where :

1. there are more than 1 business-value-columns combination that become a unique PK
2. the composite pk values get duplicated across the table details
3. cannot change the business value inside that composite PK

I know hibernate can support both types of PK, but im left wondering by my previous chats with experienced colleagues where they said that composite PK is easier to deal with when doing complex SQL queries and stored procedure processes.

They went on saying that when using surrogate keys will complicate things when doing joining and there are several condition when it's impossible to do some stuffs when using surrogate keys. Although im sorry i cant explain the detail here since i was not clear enough when they explain it. Maybe i'll put more details next time.

Im currently trying to do a project, and want to try out surrogate keys, since it's not getting duplicated across tables, and we can change the business-column values. And when the need for some business value combination uniqueness, i can use something like :

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

But im still in doubt because of the previous discussion about the composite key.

Could you share your experiences in this matter ? Thank you !

解决方案

The first rule about any application is that requirements change. Period. So, something which looks like a good candidate for a PK today may not be a PK at all tomorrow.

A value is a good candidate for a PK if it contains the following characteristics:

1. It's immutable. It will never change.
2. Uniqueness. Two records will never share the same ID.

That said, it's pretty much impossible to have anything in real world with these characteristics in a perpetual way. I mean, even if something is immutable and unique today, it doesn't means it'll always be like that.

So, go with surrogate keys whenever possible. Use natural keys only for legacy databases. And run away from those friends who suggested that natural keys are better than surrogate (kidding) :-)

And of course: you can enforce the uniqueness rule with a constraint in the database (like you did in the example), making it impossible for two records to share the same value, if that's the business rule. When the business logic changes in the future, you'll be glad to see that you used a surrogate key ;-)

But don't trust a random dude on stackoverflow for this. Read those two articles from Wikipedia:

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

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

这篇关于休眠：在复合PK对替代PK的意见的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！