Совет: идентификация SQL Server и ключи уникального идентификатора при использовании Entity Framework

Question

Я нахожусь в процессе проектирования довольно сложной системы. Одна из наших основных задач - поддержка одноранговой репликации SQL Server. Идея заключается в поддержке нескольких географически разделенных узлов.

Второстепенной проблемой является использование современного ORM на среднем уровне. Нашим первым выбором всегда был Entity Framework, главным образом потому, что разработчики любят работать с ним. (Они любят поддержку LiNQ.)

Так вот в чем проблема:

Имея в виду одноранговую репликацию, я остановился на использовании uniqueidentifier со значением по умолчанию newsequentialid () для первичного ключа каждой таблицы. Похоже, это обеспечивает хороший баланс между предотвращением коллизий ключей и уменьшением фрагментации индекса.

Однако оказывается, что текущая версия Entity Framework имеет очень странное ограничение : если ключевой столбец сущности является уникальным идентификатором (GUID), его нельзя настроить на использование значения по умолчанию (newsequentialid). ()) предоставлено базой данных. Прикладной уровень должен сгенерировать GUID и заполнить значение ключа.

Итак, вот дебаты:

1. отказаться от Entity Framework и использовать другой ORM:
   • использовать NHibernate и отказаться от поддержки LiNQ
   • использовать linq2sql и отказаться от будущей поддержки (не говоря уже о привязке к SQL Server на БД)
2. отказаться от GUID и перейти с другой стратегией PK
3. разработать метод генерации последовательных идентификаторов GUID (COMBs?) На прикладном уровне

Я склоняюсь к варианту 1 с linq2sql (мои разработчики действительно любят linq2 [stuff]) и 3. Это главным образом потому, что я несколько не знаю альтернативных ключевых стратегий, которые поддерживают схему репликации, на которую мы нацелены, при этом также сохраняя все нормально с точки зрения разработчика.

Любое понимание или мнение будет с благодарностью.

Answer 1

Я второе предложение Крейга - вариант 4.

Вы всегда можете использовать столбец GUID, заполненный промежуточным уровнем, в качестве ПЕРВИЧНОГО КЛЮЧА (это логическая конструкция).

Чтобы избежать массивной фрагментации индекса (то есть: таблицы), используйте какой-либо другой ключ (в идеале столбец INT IDENTITY) в качестве КЛЮЧЕВОГО КЛЮЧА - это физическая конструкция базы данных, которая МОЖЕТ быть отделена от первичного ключа.

По умолчанию первичным ключом является ключ кластеризации, но это не обязательно должно быть так. Фактически, я улучшил производительность и резко снизил фрагментацию, выполнив то же самое для базы данных, которую я «унаследовал» - добавив столбец INT IDENTITY и поместив ключ кластеризации в этот маленький, постоянно увеличивающийся, никогда не меняющийся INT - работает как шарм!

Марк

Answer 2

А? Я думаю, что ваши три варианта являются ложным выбором. Рассмотрим вариант 4:

4) Используйте Entity Framework с непоследовательными , сгенерированными клиентом GUID.

EF не может видеть сгенерированные DB-сервером GUID для новых строк, вставленных самой структурой , конечно, но вам не нужно генерировать GUID на сервере БД. Вы можете сгенерировать их на клиенте при создании экземпляров вашей сущности. Весь смысл GUID в том, что не имеет значения, где вы его генерируете. Что касается GUID, сгенерированных реплицированной БД, EF увидит их просто отлично.

Ваши GUID на стороне клиента не будут последовательными (используйте Guid.NewGuid ()), но они будут глобальными, гарантированно уникальными.

Мы занимаемся поставкой, производством программного обеспечения с тиражированием. Это работает .

Answer 3

Другим вариантом (недоступным, когда это было опубликовано) является обновление до EF 4, который поддерживает генерируемые сервером GUID.

Answer 4

используйте newseqid со своей собственной формой (это не так сложно) с linq

Answer 5

Вы можете использовать хранимые процедуры, если вы действительно застряли на NewSequentialID (). Вы можете привязать столбцы результата из процедуры к соответствующему свойству, и после вставки сгенерированный SQL GUID будет возвращен обратно в объект.

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

Есть пошаговый пример на http://blogs.msdn.com/bags/archive/2009/03/12/entity-framework-modeling-action-stored-procedures.aspx, который довольно прост.

Answer 6

Почему бы не использовать столбец идентификации? Если вы выполняете репликацию слиянием, каждая система может начинаться с отдельного начального числа и работать в одном направлении (например, узел a начинается с 1 и добавляет 1, узел b начинается с 0 и вычитает один) ...