Проблема с сгенерированными триггерами идентификаторов (MySQL)

Question

Я использую триггеры до и после вставки для генерации идентификаторов (первичный ключ) вида "ID_NAME-000001" в нескольких таблицах. На данный момент значение класса генератора гибернации этих pojos назначено . Случайная строка присваивается объекту, который должен быть сохранен, и при вставке в режим гибернации триггер назначает правильное значение идентификатора.

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

Полагаю, мне нужно создать собственный класс генератора, который мог бы получить значение идентификатора, назначенное триггером. Я видел пример этого для оракула (https://forum.hibernate.org/viewtopic.php?f=1&t=973262), но я не смог создать нечто подобное для MySQL. Есть идеи?

Спасибо

Обновление:

Кажется, что это общая и пока не решенная проблема. Я закончил тем, что создал новый столбец, который будет служить уникальным ключом для использования класса генератора select .

Answer 1

Надеюсь, это не приведет к священной войне за использование суррогатного ключа или нет.Но пришло время открыть диалог здесь.

Другой подход - использовать сгенерированный ключ в качестве суррогатного ключа и назначить новое поле для идентификатора, назначенного вашему триггеру.Суррогатный ключ является первичным ключом.У вас есть логически названный ключ (например, «ID_NAME-000001» в вашем примере).Таким образом, строки вашей базы данных будут иметь 2 ключа, первичный ключ - суррогатный ключ (может быть UUID, GUID, номер выполнения).Обычно такой подход предпочтительнее, потому что он может лучше адаптироваться к новым изменениям.Скажем, у вас есть эти строки, использующие суррогатный ключ вместо сгенерированного идентификатора в качестве естественного ключа.

Суррогатный ключ:

id: "2FE6E772-CDD7-4ACD-9506-04670D57AA7F", logical_id: "ID_NAME-000001", ...

Натуральный ключ:

id: "ID_NAME-000001", ...

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

С решением с суррогатным ключом это будет легко, вам просто нужно добавить

id: "2FE6E772-CDD7-4ACD-9506-04670D57AA7F", logical_id: "ID_NAME-000001", valid: "F", ...
id: "0A33BF97-666A-494C-B37D-A3CE86D0A047", logical_id: "ID_NAME-000001", valid: "T", ...

MySQL не поддерживает последовательность (автоинкремент IMO не сопоставим с последовательностью).Это отличается от последовательности Oracle / PostgreSQL.Я предполагаю, что это причина, почему трудно портировать решение с базы данных Oracle на MySQL.PostgeSQL делает.