Неверное значение для UNIQUE_CONSTRAINT_NAME в REFERENTIAL_CONSTRAINTS - PullRequest
2 голосов
/ 09 июня 2010

Я перечисляю все ограничения FK для данной таблицы, используя INFORMATION_SCHEMA набор представлений со следующим запросом:

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?

1 Ответ

4 голосов
/ 09 июня 2010

Поскольку в одном и том же столбце есть ограничения PK и UNIQUE, SQL Server выбирает один из них для использования.Я не знаю, выбирает ли он ограничение UNIQUE, потому что оно тоньше (то есть меньше столбцов) и может потребовать меньше операций чтения для подтверждения совпадений (?)

Я не вижу никакого способа в SQL, чтобы обеспечитьодин, который он выбирает, кроме заказа ваших скриптов - создайте таблицу с PK, создайте другую таблицу и FK, затем создайте уникальное ограничение, если оно вам действительно нужно - но так ли это на самом деле?

...