SQL Server 中的键是全局的 - 为什么？
MS SQL Server 中的索引和约束对于定义它们的表而言是本地的。因此，您可以毫无问题地在多个表中创建相同的索引或约束名称。
外键约束（每个人都应该知道不是键，而是约束）将出现在 Keys 子文件夹中，并且它们的名称似乎是全局范围的。
有人知道为什么“键”具有全局范围的名称吗？ 我确实理解键和索引之间的区别。 我不明白为什么名称范围应该有这样的差异。 在所有情况下，它们对于为其定义的表来说都是“本地的”。
TIA
Indexes and Constraints in MS SQL Server are local to the table they are defined in. So you can create the same index or constraint name in more than one table with no trouble.
Foreign Key Constraints (which as everyone should know are NOT keys, but constraints) will appear in the Keys subfolder and their names appear to be globally scoped.
Anybody know why "keys" have globally scoped names? I do understand the differences between keys and indexes. I don't understand why there should be such a difference in name scoping. In all the cases they are "local" to the table they are defined for.
TIA
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据 Peter Gulutzan 和 Trudy Pelzer 的“SQL-99 Complete,Really”，约束名称由它们所在的架构限定，并且约束影响的表必须位于同一架构中。 但约束名称未由该表名称限定。 约束名称在它所在的架构中必须是唯一的。
myschema.some_primary_keymyschema.mytable.some_primary_key至于“为什么”会出现这种情况，我假设它与 SQL-99 中一种称为
ASSERTION的约束有关。 断言并不像主键、外键和检查约束那样“属于”单个表。 断言声明一个条件，任何 INSERT/UPDATE/DELETE 都必须满足该条件才能成功，并且断言可以引用多个表。 通过任何表来限定这些约束名称是没有意义的。我不知道有多少RDBMS品牌实现了SQL断言（实际上我一个也不知道），但他们不妨遵守约束名称的标准SQL规则，所以将来他们可以选择实现断言符合标准的功能。
According to "SQL-99 Complete, Really" by Peter Gulutzan and Trudy Pelzer, constraint names are qualified by the schema in which they live, and the table that the constraint affects must live in the same schema. But the constraint name is not qualified by that table name. The constraint name must be unique within the schema it lives in.
myschema.some_primary_keymyschema.mytable.some_primary_keyAs for "why" this is the case, I assume it's related to a kind of constraint in SQL-99 called an
ASSERTION. An assertion doesn't "belong to" a single table, as is true for primary key, foreign key, and check constraints. An assertion declares a condition that must be true for anyINSERT/UPDATE/DELETEto succeed, and the assertion can reference multiple tables. It wouldn't make sense to qualify these constraint names by any table.I don't know how many RDBMS brands implement SQL assertions (actually I don't know a single one), but they might as well conform to the standard SQL rules for constraint names, so in the future they can choose to implement the assertion feature according to the standard.