Может кто-нибудь помочь мне понять, почему автоидентификация (int) плоха при использовании NHibernate?

Question

Я видел много комментариев (с точки зрения NHibernate) об использовании Guid, а не int (и, вероятно, автоматического идентификатора в базе данных), с выводом, что использование автоматической идентификации нарушает шаблон UoW.

В этом сообщении есть краткое описание проблемы, но на самом деле она не говорит мне "почему", это нарушает схему (если я не понимаю, что, вероятно, имеет место.

Может ли кто-нибудь просветить меня?

Answer 1

Есть несколько основных причин.

• Использование Guid дает вам возможность идентифицировать один объект во многих базах данных, включая шесть реляционных баз данных с одинаковой схемой, но разными данными, базу данных документов и т. Д. Это становится важным в любое время, когда у вас есть больше кроме одного места, куда отправляются данные - и это означает, что и ваш случай: у вас есть база данных dev и база данных prod, верно?

• Использование Guid дает NHibernate возможность пакетировать больше операторов вместе, выполнять больше работы с базой данных в самом конце единицы работы / транзакции и сокращать общее количество обращений к базе данных, повышая производительность а также предоставление других преимуществ.

Комментарий:

Случайные Guid s не создают плохие индексы - изначально они создают плохие кластеризованные индексы. Есть два решения.

• Использовать частично последовательный Guid. С NHibernate это означает использование генератора идентификаторов guid.comb вместо генератора идентификаторов guid. guid.comb является частично последовательным для хорошей производительности, но сохраняет очень высокую степень случайности.

• Пусть ваш первичный ключ Guid будет индексом nonclustered, и поместите кластерный индекс в другой столбец с автоинкрементом. Вы можете решить сопоставить этот столбец, и в этом случае вы теряете преимущество лучшей пакетной обработки и меньшего количества обратных вызовов, но вы получаете все преимущества коротких номеров, которые легко помещаются в URL. Или вы можете решить не отображать этот столбец и оставить его полностью в базе данных, и в этом случае вы получите лучшую производительность для Guid s в качестве первичных ключей, а также лучшую производительность для NHibernate, выполнив меньше циклических обращений.

Answer 2

Мое предположение заключается в том, что ключевым фактором является то, что для получения автоинкрементного значения требуется фактическая запись в базу данных, которую nHibernate мог бы отложить или, возможно, никогда не выполнить.

Answer 3

При использовании идентификатора и в сценарии «родитель-потомок» в базе данных есть обход базы данных, чтобы получить идентификатор родителя, чтобы она могла правильно связать дочерний элемент. Это означает, что родитель должен быть зафиксирован в это время. В случае возникновения проблемы с ребенком вам необходимо удалить родителя, чтобы правильно выйти из UoW.