Переключиться с nHibernate HiLo на GUID

Question

Можно ли перейти с HiLo на GUID.comb?Насколько я могу судить, последний сочетает в себе преимущество HiLo, а именно управление идентификаторами на стороне клиента вместо необходимости обращаться к БД для получения нового идентификатора, с тем преимуществом, что без идентификаторов невозможно работать.

В настоящее время мы сталкиваемся с проблемами с HiLo, генерирующими идентификаторы, настолько большие, что Int32 (это должен быть Int64, но это скорее WTF моего предшественника) недостаточно велик.Мы можем перейти на Int64, но это просто означает, что мы столкнемся с проблемой позже, а не раньше.

Поскольку идентификаторы не должны быть значимыми, переключение на GUID кажется логичным.Однако, поскольку я никогда не пробовал такого переключения, мне было интересно, может ли кто-нибудь здесь помочь мне оценить воздействие, которое могло бы иметь что-то подобное.

Answer 1

На самом деле, переключения на int64 обычно достаточно.Помните, что вы добавляете еще 32 бита, которые умножают пространство идентификаторов на +/- 2 миллиарда .Вы уверены, что этого недостаточно?

Что касается переключения на Guid, оно включает (при условии, что БД работает):

• Создание новых столбцов pk / fk
• Заполнениестолбцы pk с новыми значениями
• заполнение столбцов fk на основе старых
• удаление текущих внешних и первичных ключей
• удаление старых столбцов pk / fk
• Создание новых первичных и внешних ключей
• Изменение типов и идентификаторов свойств идентификатора (это единственный шаг, связанный с кодом .net)

В любом случае, в то время как GUID предоставляет «неограниченные» идентификаторы, и этоего легко генерировать, его недостатком является то, что он в два раза больше (128 бит) и немного сложнее манипулировать вручную (т.е. вы будете зависеть от копирования и вставки при отладке