миграция класса гибернации из целочисленного первичного ключа на основе последовательности в первичный ключ GUID с сохранением старых ключей для обратной совместимости?

Question

Какая стратегия подходит для переноса класса гибернации из целочисленного первичного ключа на основе последовательности в первичный ключ GUID при сохранении старых ключей для обратной совместимости?

У нас есть обширная иерархия классов (с использованием модели объединенных подклассов), где базовый класс имеет длинный первичный ключ, сгенерированный из последовательности в БД.

Мы работаем над переходом на первичный ключ GUID, но хотим сохранить старый первичный ключ (как в старом, так и во вновь созданном контенте) для устаревших приложений. Хотя реализация кажется довольно простой (измените первичный ключ на GUID, добавьте перехватчик для заполнения идентификатора контента для нового контента), о каких подводных камнях я мог бы ожидать?

Answer 1

Вы уверены, что хотите это сделать?

Я понимаю, что хочу GUID, но вы действительно хотите, чтобы они были вашими PK базы данных. Некоторое неофициальное тестирование, которое я провел, показало, что использование GUID PK для соединений / поисков по сравнению с целочисленным PK было на 10-15% больше. Я бы посоветовал вам опробовать некоторые тесты с GUID для вашего текущего населения и посмотреть, как снизится производительность. Может быть, лучше просто добавить уникально индексированный столбец GUID в ваши таблицы и оставить PK как есть.

Answer 2

Я не могу придумать красивое решение, но,

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

Answer 3

Глупые ошибки типа «мы знаем, что PK - это GUID, поэтому его длина всегда так велика» ...