Отложенные ограничения в SQL Server

Пока SQL Server не поддерживает их. В чем проблема, которую вы решаете?

OT: Есть IMHO немало вещей, которые SQL Server не поддерживает, но имеет смысл в корпоративной среде:

• Отложенные ограничения, упомянутые здесь
• МАРС: Почему вам нужно установить вариант для чего-то совершенно естественного?
• Ограничения CASCADE DELETE: SQL Server допускает только один каскадный путь для данного ограничения CASCADE DELETE. Опять же, я не вижу причин, по которым не следует разрешать каскад при удалении с помощью нескольких возможных путей: в конце концов, в то время, когда он действительно выполняется, всегда будет использоваться только один путь, поэтому почему это ограничение?
• Предотвращение параллельных транзакций в одном соединении ADO.NET.
• Принуждение каждой команды, выполняемой в соединении, которое имеет транзакцию, выполняемую в рамках этой транзакции.
• При создании индекса UNIQUE NULL обрабатывается так, как если бы он был фактическим значением, и ему разрешалось появляться только один раз в индексе. Однако представление SQL о NULL как «неизвестном значении» указывает, что значения NULL вообще игнорируются при создании индекса ...

Все эти мелочи делают многие из ссылочной целостности и транзакционных функций, которые вы ожидаете от полноразмерной СУБД, почти бесполезной в SQL Server. Например, поскольку отложенные ограничения не поддерживаются, понятие «транзакция» как внешне согласованное подразделение работы частично отрицается, единственное жизнеспособное решение - за исключением некоторых грязных обходных решений - заключается в том, чтобы вообще не определять ограничения ссылочной целостности. Я бы ожидал, что естественное поведение транзакции заключается в том, что вы можете работать внутри нее в порядке и порядке операций, которые вам нравятся, и система будет следить за тем, чтобы она была согласованной в момент ее совершения. Подобные проблемы возникают из-за ограничения, что ограничение ссылочной целостности с ON DELETE CASCADE может быть определено только таким образом, что только одно ограничение может привести к каскадному удалению объекта. Это действительно не подходит для большинства реальных сценариев.

Очевидно нет.

Я обнаружил около пяти разных сообщений в блогах, говорящих, что SQLServer (в разных версиях) не поддерживает Deferrable Constraints.

С другой стороны, я также нашел сообщение, которое пытается воспроизвести эту функцию, используя «постоянные вычисленные столбцы» (прокрутите до последней записи), но предостерегайте emptor

Похоже, что проблема заключается в том, что SQL не поддерживает то, что Date и Darwen называют «множественным назначением». Ответ SQL Server на это был «отложенными ограничениями», которые SQL Server не поддерживает. Ограничение SQL Server FK или CHECK может быть помечено NOCHECK, но это не совсем то же самое. Подробнее см. MSDN: ALTER TABLE (Transact-SQL) .

Если у вас есть собственный уровень ORM, одним из решений вашей проблемы может быть разделение обновления объекта с помощью эталонного обновления по логике вашего уровня ORM. Затем ваш ORM будет работать с транзакциями на основе изменения клиентской стороны несколькими шагами:

1. Удалите все ссылки на внешние ключи, определенные вашим набором изменений, как удаленные, то есть установите соответствующие столбцы внешнего ключа в NULL или для отношений, использующих таблицы сопоставления, DELETE записей из таблиц сопоставления, если это необходимо.
2. Удалите все объекты, определенные как «удаленные» вашими наборами изменений
3. Создайте все новые объекты в своем наборе изменений, но еще не установите столбцы внешнего ключа
4. Обновите все «примитивные» изменения значений для любых обновленных объектов в наборе изменений, то есть не обновляйте столбцы внешнего ключа
5. Задайте значения столбцов внешнего ключа, как определено в вашем наборе изменений.
6. Добавление сопоставлений таблицы сопоставлений для сопоставления табличных отношений
7. совершить

Это должно решить вашу проблему, поскольку все ссылки на объекты существуют в любое время, когда установлено значение внешнего ключа ...