Генерация первичных ключей Hibernate
Выбор генератора влияет не только на вид ключа, но и на batch insert, индексы и переносимость.
| Стратегия | Когда ключ известен | Особенность |
|---|---|---|
IDENTITY | после/во время INSERT | просто, но часто ограничивает batch |
SEQUENCE | до INSERT | можно резервировать блоки |
TABLE | после блокировки строки генератора | переносимо, но создаёт конкуренцию |
UUID | в приложении или провайдере | не нужен центральный sequence, ключ шире |
AUTO | зависит от выбора провайдера | удобно, но менее явно |
Как выбирать
- PostgreSQL и Oracle хорошо работают с sequence;
- identity естественна для БД с auto-increment, если batch не критичен;
- UUID удобен для распределённого создания, но формат и порядок влияют на индекс;
- бизнес-номер не следует использовать как технический PK только ради «красивой» последовательности.
Hibernate может оптимизировать sequence через pooled allocation. Поэтому sequence в БД и значения приложения могут идти с пропусками — это штатно.
Вопросы для повторения
- Какая стратегия позволяет получить ID до INSERT? Обычно
SEQUENCEи UUID. - Почему ключи имеют пропуски? Резервирование диапазона, rollback и перезапуски.
- Можно ли обещать пользователю последовательный номер по PK? Нет, для этого нужен отдельный бизнес-механизм.
- Что выбрать для batch insert? Часто sequence с allocation; решение подтверждают измерением на конкретной БД.
Связано: Аннотация GeneratedValue, Как смапить составной ключ, Hibernate.