为什么SSDT会像NOCHECK那样部署内联FK约束？

Question

给定SSDT项目中Create定义的下列外键约束定义：

CREATE TABLE A
(...Columns...),
CONSTRAINT [FK_O] FOREIGN KEY ([OID]) REFERENCES [dbo].[O] ([ID]) ON DELETE CASCADE NOT FOR REPLICATION,
(...)

和下面的来自MSDN的报价

使用NOCHECK指定表中的数据是否根据新添加的或重新启用的外键或CHECK约束进行验证。如果未指定，则假定WITH为新约束，NOCHECK为重新启用约束。

，我想知道为什么这个新表的第一个部署结果与使用NOCHECK选项的约束类似，如下所示：

ALTER TABLE [dbo].[A]  WITH NOCHECK ADD CONSTRAINT [FK_O] FOREIGN KEY([OID])
REFERENCES [dbo].[O] ([ID])
ON DELETE CASCADE
NOT FOR REPLICATION 
GO

ALTER TABLE [dbo].[A] CHECK CONSTRAINT [FK_O]
GO

所以问题是，不允许定义"with Nocheck“的内联约束定义与MSDB页面中的规则配对，难道不应该使用这个新表上的with CHECK选项将其转化为约束吗？为什么我们在这里得到一个带有NOCHECK约束的？

Answer 1

NOT FOR REPLICATION意味着，即使您显式地检查约束，也不会检查它。

很可能，这里的SSDT是显式的，这是隐式的。

Answer 2

只有一种外键约束(尽管它可以是可信的，也可以是不可信的)。

如果它是一个新表，那么这两个代码路径本质上是相同的。但是他们这样做是因为SSDT考虑到了它可能需要调整DDL以添加到现有的表中。

• 如果存在该表，并且它使用check更改了该表，则部署将失败，并且不会在该表上设置check约束。
• 如果该表存在，并且它用nocheck修改了表，然后留下检查，则如果旧数据不符合条件，您将得到一个错误，但至少模式更改将到位。

他们所做的是生成一组一致的代码，涵盖了不存在的和现有的可能性。他们并没有试图对每个用例进行优化。

从本质上讲，它没有进一步的内在含义。这只是他们如何输出代码的一个假象。