Нужно ли использовать GUID в приложении LinqToSql для уникальной идентификации объектов?

Question

Я унаследовал приложение LinqToSql, которое использует ключи GUID для объектов.Я бы предпочел использовать обычные поля идентификации - гораздо проще для людей использовать, понимать и общаться.Однако есть некоторая бизнес-логика, которая требует, чтобы приложение идентифицировало уникальные объекты, прежде чем они будут сохранены в БД, поэтому GUID, где они используются в первую очередь.

Другая проблема, с которой мы сталкиваемся, связана с фрагментированными индексами -AFAIK, мы не можем создавать последовательные идентификаторы GUID в коде .Net.

Поскольку это мое первое упражнение в LinqToSql, я хотел бы знать, как другие решают эту проблему.

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

Answer 1

Нет, вам не нужно использовать Guids, вы можете использовать любой тип ключа, который вы хотите.

Если вы застряли с Guids, подумайте, чтобы база данных генерировала их для вас последовательно, сделав привязку по умолчанию для поля pk newsequentialid().Это по крайней мере устранит фрагментацию в вашем кластерном индексе.Вам нужно внести несколько изменений в .dbml, если вы это сделаете.В ключевом поле в .dbml Auto Generated Value = true и Auto-Sync = OnInsert

Что касается генерации значения перед вставкой в ​​базу данных, я не вижу, как использование поля идентификации помогает вам.Вам все равно придется вставить в базу данных, чтобы надежно получить правильное значение.(Столбцы идентификаторов будут иметь те же параметры автоматического создания / автосинхронизации, что и выше)

Ints или Guids, вы должны иметь возможность заключить вставку в транзакцию, вставить запись, получить новое значение ключа, запустить свою бизнес-логикуи, если это не удается, откатите вновь вставленную запись.