生成的脚本中的 SQL Server Check/NoCheck 差异答案

【问题标题】：SQL Server Check/NoCheck difference in generated scripts生成的脚本中的 SQL Server Check/NoCheck 差异
【发布时间】：2010-11-23 04:55:06
【问题描述】：

我正在尝试将架构同步到不同的数据库。基本上，我在两个数据库上运行任务->使用 SQL Server Management Studio (2005) 生成脚本，并将输出与差异工具进行比较。

由于某种原因，一个脚本添加了约束 WITH CHECK 和一个 WITH NO CHECK，然后重新启用这两个约束。

我获得的第一个数据库：

ALTER TABLE [dbo].[Profile]  WITH CHECK ADD  CONSTRAINT [FK_Profile_OrganizationID] FOREIGN KEY([OrganizationID])
REFERENCES [dbo].[Organization] ([OrganizationID])
GO
ALTER TABLE [dbo].[Profile] CHECK CONSTRAINT [FK_Profile_OrganizationID]
GO

第二个数据库生成为

ALTER TABLE [dbo].[Profile]  WITH NOCHECK ADD  CONSTRAINT [FK_Profile_OrganizationID] FOREIGN KEY([OrganizationID])
REFERENCES [dbo].[Organization] ([OrganizationID])
GO
ALTER TABLE [dbo].[Profile] CHECK CONSTRAINT [FK_Profile_OrganizationID]
GO

所以我有两个问题：

最终结果是否相同？（编辑： 似乎很多人只接受这两个脚本的第一条语句。我对这两个脚本的最终结果很感兴趣。）
如果最终结果相同，为什么 Management Studio 会针对不同的数据库生成不同的结果？

【问题讨论】：

标签： sql-server sql-server-2005

【解决方案1】：

是的，这两个脚本不同

WITH CHECK 将根据新限制检查现有数据。
WITH NOCHECK 不会根据新限制检查现有数据。这将允许您拥有没有相应父项的子记录。

编辑：至于SSMS为什么要这样做我不知道

【讨论】：

但是，如果您查看两个脚本脚本，在添加约束后立即出现 ALTER TABLE [dbo].[Profile] CHECK CONSTRAINT [FK_Profile_OrganizationID] GO 不检查约束在那一点？

【解决方案2】：

最终结果不一样！

如果未检查 FK，SQL Server 将不信任 FK 的唯一性。这意味着如果您在查询中使用该列，则需要进行额外处理。
长话短说，您应该让 SQL Server 检查该列，以便它被认为是可信的。

至于为什么它们与不同的服务器不同，请查看 sys.foreign_keys 中的 isnottrusted 列。这可能会影响 SSMS 生成的内容？

如需更多关于此的咆哮，请查看与 FK & NO CHECK/CHECK 选项相关的 my other answer。

【讨论】：

但是，如果您查看这两个脚本脚本，在添加约束后立即出现 ALTER TABLE [dbo].[Profile] CHECK CONSTRAINT [FK_Profile_OrganizationID] GO 不检查约束在那一点？
至于答案的第二部分，您确实是正确的，is_not_trusted 设置在一个数据库上，而不是另一个数据库上。这有什么影响？
找到这篇文章：sqlblog.com/blogs/tibor_karaszi/archive/2008/01/12/… 所以看来批处理中的第二条语句只确保启用了约束，它实际上并没有检查现有数据。要实际检查现有数据，我需要 ALTER TABLE 吗？ WITH CHECK CHECK CONSTRAINT all
很高兴它的排序！似乎 SSMS 会生成不同的代码，因此您最终会在 isnottrusted 列中得到相同的结果。我的猜测是这是设计使然。

【解决方案3】：

两者都是 SQL Server 2005 服务器？由于结果相同，代码生成工具可能会根据产品的不同版本使用不同的例程

【讨论】：

实际上，在这个特定的时间点，两个数据库都在同一台服务器上 - 所以绝对没有任何 Sql Server 版本差异