Я занимаюсь разработкой довольно сложной системы. Одной из наших основных задач является поддержка одноранговой репликации SQL Server. Идея состоит в том, чтобы поддерживать несколько географически разделенных узлов.
Второстепенной проблемой было использование современного ORM на среднем уровне. Нашим первым выбором всегда был Entity Framework, главным образом потому, что разработчикам нравится работать с ним. (Им нравится поддержка LiNQ.)
Итак, вот проблема:
Имея в виду одноранговую репликацию, я решил использовать uniqueidentifier со значением по умолчанию newsequentialid() для первичного ключа каждой таблицы. Казалось, что это обеспечивает хороший баланс между предотвращением конфликтов ключей и уменьшением фрагментации индекса.
Однако оказывается, что текущая версия Entity Framework имеет очень странное ограничение: если ключевой столбец сущности является уникальным идентификатором (GUID), то его нельзя настроить для использования значения по умолчанию (newsequentialid()), предоставленного базой данных. Уровень приложения должен сгенерировать GUID и заполнить значение ключа.
Итак, вот обсуждение:
- abandon Entity Framework and use another ORM:
- use NHibernate and give up LiNQ support
- использовать linq2sql и отказаться от поддержки в будущем (не говоря уже о привязке к SQL Server в БД)
- отказаться от GUID и использовать другую стратегию PK
- разработать метод генерации последовательных идентификаторов GUID (COMB?) на прикладном уровне.
Я склоняюсь к варианту 1 с linq2sql (моим разработчикам очень нравится linq2[stuff]) и 3. Это в основном потому, что я несколько не знаком с альтернативными ключевыми стратегиями, которые поддерживают схему репликации, к которой мы стремимся, и в то же время сохраняем здравомыслие. точка зрения разработчика.
Любое понимание или мнение будет принята с благодарностью.