Допускающие задержку ограничения в SQL Server

Apparently not.

I found about five different blog posts all saying SQLServer (in various versions) does not support Deferrable Constraints.

On the other hand, I also found a post which attempts to mimic this feature by using "persisted computed columns," (scroll to the last entry), but caveat emptor

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

OT: ИМХО, есть довольно много вещей, которые SQL Server не поддерживает, но имеет смысл в корпоративной среде:

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

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