REFERENTIAL_CONSTRAINTS 中的 UNIQUE_CONSTRAINT_NAME 值不正确
我使用 INFORMATION_SCHEMA
视图集和以下查询列出给定表的所有 FK 约束:
SELECT X.UNIQUE_CONSTRAINT_NAME,
"C".*, "X".*
FROM "INFORMATION_SCHEMA"."KEY_COLUMN_USAGE" AS "C"
INNER JOIN "INFORMATION_SCHEMA"."REFERENTIAL_CONSTRAINTS" AS "X"
ON "C"."CONSTRAINT_NAME" = "X"."CONSTRAINT_NAME"
AND "C"."TABLE_NAME" = 'MY_TABLE'
AND "C"."TABLE_SCHEMA" = 'MY_SCHEMA'
一切都运行良好,但对于一个特定约束,UNIQUE_CONSTRAINT_NAME
列的值为错误,我需要它才能从引用的专栏中找到更多信息。基本上,对于大多数行,UNIQUE_CONSTRAINT_NAME
包含引用表中唯一约束(或 PK)的名称,但对于一个特定的 FK
,它是某些约束的名称。其他独特的约束。
我删除并重新创建了 FK - 没有帮助。
我的假设是元数据在某种程度上被搞砸了。有没有办法重建元数据,以便 INFORMATION_SCHEMA
视图实际上显示正确的数据?
edit-1:示例数据库结构
CREATE TABLE MY_PARENT_TABLE (
ID INTEGER,
NAME VARCHAR,
--//...
CONSTRAINT MY_PARENT_TABLE_PK PRIMARY KEY CLUSTERED (ID)
)
CREATE UNIQUE NONCLUSTERED INDEX MY_PARENT_TABLE_u_nci_ID_LongName ON MY_PARENT_TABLE (ID ASC) INCLUDE (SOME_OTHER_COLUMN)
CREATE TABLE MY_CHILD_TABLE (
ID INTEGER,
PID INTEGER,
NAME VARCHAR,
CONSTRAINT MY_CHILD_TABLE_PK PRIMARY KEY CLUSTERED (ID)
,CONSTRAINT MY_CHILD_TABLE__MY_PARENT_TABLE__FK
FOREIGN KEY (PID)
REFERENCES MY_PARENT_TABLE (ID)
ON UPDATE NO ACTION
ON DELETE NO ACTION
)
我希望UNIQUE_CONSTRAINT_NAME
是MY_PARENT_TABLE_PK
,但我是什么 获取的是MY_PARENT_TABLE_u_nci_ID_LongName
。
查看结构后,我发现实际上该列上有 2 个 UNIQUE
约束 - PK
和 MY_PARENT_TABLE_u_nci_ID_LongName
。所以真正的问题可能应该是:为什么它需要一些其他唯一索引而不是 PK?
I am listing all FK constraints for a given table using INFORMATION_SCHEMA
set of views with the following query:
SELECT X.UNIQUE_CONSTRAINT_NAME,
"C".*, "X".*
FROM "INFORMATION_SCHEMA"."KEY_COLUMN_USAGE" AS "C"
INNER JOIN "INFORMATION_SCHEMA"."REFERENTIAL_CONSTRAINTS" AS "X"
ON "C"."CONSTRAINT_NAME" = "X"."CONSTRAINT_NAME"
AND "C"."TABLE_NAME" = 'MY_TABLE'
AND "C"."TABLE_SCHEMA" = 'MY_SCHEMA'
Everything works perfectly well, but for one particular constraint the value of UNIQUE_CONSTRAINT_NAME
column is wrong, and I need it in order to find additional information from the referenced Column. Basically, for most of the rows the UNIQUE_CONSTRAINT_NAME
contains the name of the unique constraint (or PK) in the referenced table, but for one particular FK
it is the name of some other unique constraint.
I dropped and re-created the FK - did not help.
My assumption is that the meta-data is somehow screwed. Is there a way to rebuild the meta data so that the INFORMATION_SCHEMA
views would actually show the correct data?
edit-1: sample db structure
CREATE TABLE MY_PARENT_TABLE (
ID INTEGER,
NAME VARCHAR,
--//...
CONSTRAINT MY_PARENT_TABLE_PK PRIMARY KEY CLUSTERED (ID)
)
CREATE UNIQUE NONCLUSTERED INDEX MY_PARENT_TABLE_u_nci_ID_LongName ON MY_PARENT_TABLE (ID ASC) INCLUDE (SOME_OTHER_COLUMN)
CREATE TABLE MY_CHILD_TABLE (
ID INTEGER,
PID INTEGER,
NAME VARCHAR,
CONSTRAINT MY_CHILD_TABLE_PK PRIMARY KEY CLUSTERED (ID)
,CONSTRAINT MY_CHILD_TABLE__MY_PARENT_TABLE__FK
FOREIGN KEY (PID)
REFERENCES MY_PARENT_TABLE (ID)
ON UPDATE NO ACTION
ON DELETE NO ACTION
)
I expect the UNIQUE_CONSTRAINT_NAME
to be MY_PARENT_TABLE_PK
, but what I am
getting is MY_PARENT_TABLE_u_nci_ID_LongName
.
Having looked at the structure, I see that in fact there are 2 UNIQUE
constaints on that column - PK
and the MY_PARENT_TABLE_u_nci_ID_LongName
. So the real question should probably be: why does it take some other unique index and not the PK?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
由于同一列上同时具有 PK 和 UNIQUE 约束,因此 SQL Server 会选择使用一个。我不知道它是否选择 UNIQUE 约束,因为它更薄(即涉及的列更少)并且可能需要更少的读取来确认匹配(?)
我在 SQL 中看不到任何方法来强制它选择哪一个,除了排序你的脚本 - 创建带有 PK 的表,创建另一个表和 FK,然后创建 UNIQUE 约束(如果你确实需要) - 但事实真的是这样吗?
Since you have both a PK and a UNIQUE constraint on the same column, SQL Server picks one to use. I don't know if it picks the UNIQUE constraint because it is thinner (i.e. fewer columns involved) and might require fewer reads to confirm matches(?)
I don't see any way within SQL to enforce which one it chooses, other than ordering your scripts - create the table with the PK, create the other table and the FK, then create the UNIQUE constraint if you really need it - but is that really the case?