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

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

出于某种原因,一个脚本添加了约束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会针对不同的数据库生成不同的结果？

Cory.. 20

是的,他们两个脚本是不同的

WITH CHECK将根据新约束检查现有数据.
WITH NOCHECK 不会根据新约束检查现有数据.这将允许您拥有没有相应父级的子记录.

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

1> Cory..：

---

是的,他们两个脚本是不同的

WITH CHECK将根据新约束检查现有数据.
WITH NOCHECK 不会根据新约束检查现有数据.这将允许您拥有没有相应父级的子记录.

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

2> Nick Kavadia..：

---

最终的结果是不一样的!

如果没有检查,SQL Server将不信任FK的唯一性.这意味着如果在查询中使用该列,则需要进行其他处理.
简而言之,您应该让SQL Server检查列,以便它被认为是可信的.

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

有关这方面的更多咆哮,请查看我与FK和NO CHECK/CHECK选项相关的其他答案.

---

发现这篇文章:http://sqlblog.com/blogs/tibor_karaszi/archive/2008/01/12/non-trusted-constraints.aspx因此,批处理中的第二个语句似乎只能确保启用约束,它实际上并没有检查现有数据.要实际检查现有数据,我需要ALTER TABLE？检查CHECK CONSTRAINT全部