【问题标题】:Non-scriptable foreign key不可编写脚本的外键
【发布时间】:2017-09-06 21:06:13
【问题描述】:

这是我面临的问题:

我有一个包含几个外键的表。当我在 SSMS 中将表编写为“创建到新查询”窗口时,其中一个没有被编写脚本,但其余的却被编写了脚本。它也不会出现在对象资源管理器的 Keys 文件夹中。

它出现的唯一方式是当我在 SSMS 中打开表的设计视图时,右键单击设计窗口并选择关系。然后它按预期显示(连同其余的外键)。

我相当有信心通过 SSMS 设计向导创建了此密钥。

引起我注意的原因是我在 Visual Studio 2015 中运行了数据库架构比较来部署我的更改,但它也没有将其显示为差异(Visual Studio 中的设计没有显示它,对于脚本编写也是如此表 Visual Studio)。但是,我记得设置了这个外键并查看了它,发现它不太对劲。

如何解释/避免这种情况?

【问题讨论】:

  • 不使用表编写脚本的外键是否是表中被另一个表引用的列,而不是引用另一个表?如果是这样,那么外键将由引用表而不是父/源表编写脚本。
  • @SqlZim:我不确定有什么区别。不是脚本的 FK 是 (int, not null) 类型的列。它也是正在编写脚本的表中的 PK。它用作另一个表中的主键。这是 1 到(0 或 1)的关系。
  • 当您为另一个表编写脚本时,您要查找的外键是否已编写脚本?
  • 从不使用 SSMS 设计向导可以避免这种情况。您能否添加一张您所看到的让您认为 FK 存在的屏幕截图?
  • 外键是一个约束,并且该约束存在于引用另一个表(而不是被引用的表)的表上。这样就可以解释为什么在编写该约束所引用的父表的脚本时看不到它。

标签: sql-server tsql sql-server-2014


【解决方案1】:

是的,当我为我正在寻找的另一个表外键编写脚本时 脚本化

这就是答案。 FK 存在于另一张桌子上。不是您正在查看的表格。这就是它没有被编写脚本的原因。

【讨论】:

  • 我现在感觉自己像个白痴。话虽如此,它也显示为另一张桌子上的关系。 SSMS 仅在一个地方将其显示为关系以保持一致不是很有意义吗?
  • 我想有足够多的人希望看到 SSMS 中的关系,而不管表格位于关系的哪一侧。
猜你喜欢
  • 2018-03-31
  • 1970-01-01
  • 2014-10-31
  • 1970-01-01
  • 2021-03-27
  • 2012-12-31
  • 2010-09-05
  • 2011-07-13
  • 1970-01-01
相关资源
最近更新 更多