Hibernate: мнения в композитных ПК против суррогатных ПК

Question

Как я понимаю, всякий раз, когда я использую @Id и @GeneratedValue в поле Long внутри сущности JPA / Hibernate, я на самом деле использую суррогатный ключ, и я думаю, что это очень хороший способ определить первичный ключ, учитываямой не очень хороший опыт использования составных первичных ключей, где:

1. существует более 1 комбинации столбцов бизнес-значений, которые становятся уникальными PK
2. составными значениями pkдублировать данные таблицы
3. не может изменить бизнес-ценность внутри этого составного ПК

Я знаю, что hibernate может поддерживать оба типа ПК, но я уже удивляюсь, что мои предыдущие чаты с опытнымиколлеги, которые сказали, что с сложным PK легче иметь дело при выполнении сложных запросов SQL и процессов хранимых процедур.

Они продолжали говорить, что при использовании суррогатных ключей все усложняется при объединении, и есть несколько условий, когда невозможно использовать некоторые вещи при использовании суррогатных ключей.Хотя я извиняюсь, я не могу объяснить детали здесь, так как я не был достаточно ясен, когда они это объясняют.Возможно, я добавлю больше деталей в следующий раз.

В настоящее время я пытаюсь создать проект и хочу попробовать суррогатные ключи, поскольку он не дублируется в таблицах, и мы можем изменить значения бизнес-столбцов.И когда мне нужна некоторая уникальность комбинации бизнес-ценности, я могу использовать что-то вроде:

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

Но я все еще сомневаюсь из-за предыдущего обсуждения составного ключа.

Не могли бы вы поделиться?ваш опыт в этом вопросе?Спасибо!

Answer 1

Первое правило для любого приложения - изменение требований. Период. Таким образом, то, что выглядит хорошим кандидатом на ПК сегодня, может вообще не быть ПК завтра.

Значение является хорошим кандидатом для PK, если оно содержит следующие характеристики:

1. Это неизменное. Это никогда не изменится.
2. единственность. Две записи никогда не будут иметь один и тот же идентификатор.

Тем не менее, практически невозможно иметь что-либо в реальном мире с этими характеристиками вечно. Я имею в виду, даже если что-то неизменное и уникальное сегодня, это не значит, что так будет всегда.

Так что, по возможности, используйте суррогатные ключи. Используйте естественные ключи только для устаревших баз данных. И убегите от тех друзей, которые предположили, что натуральные ключи лучше суррогатных (шучу): -)

И конечно: вы можете применить правило уникальности с помощью ограничения в базе данных (как вы сделали в примере), что делает невозможным совместное использование двумя записями одного и того же значения, если это бизнес-правило. Когда бизнес-логика изменится в будущем, вы будете рады видеть, что вы использовали суррогатный ключ; -)

Но не доверяйте этому случайному чуваку в стеке потока. Прочитайте эти две статьи из Википедии:

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

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

Answer 2

Hibernate, кажется, поощряет использование суррогатных ключей. Я предпочитаю использовать составные ключи, но не хочу бороться с фреймворком, а в Hibernate составные ключи могут стать обременительными. Поэтому, чтобы получить лучшее из обоих миров, я использую суррогатный ключ, но также помечаю свои потенциальные столбцы составного ключа с помощью @NaturalId, чтобы Hibernate создавал для меня уникальные ограничения. По умолчанию изменяемость @NaturalId равна false, поэтому если вам нужно обновить поле «составной ключ», используйте @NaturalId (mutability = true).