REFERENTIAL_CONSTRAINTS 中的 UNIQUE_CONSTRAINT_NAME 值不正确

发布于 2024-09-05 03:01:25 字数 1720 浏览 8 评论 0原文

我使用 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_NAMEMY_PARENT_TABLE_PK,但我是什么 获取的是MY_PARENT_TABLE_u_nci_ID_LongName

查看结构后,我发现实际上该列上有 2 个 UNIQUE 约束 - PKMY_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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

想念有你 2024-09-12 03:01:25

由于同一列上同时具有 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?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文