Valeur incorrecte pour UNIQUE_CONSTRAINT_NAME dans referential_constraints

Question

Je suis annonce toutes les contraintes FK pour une table donnée en utilisant INFORMATION_SCHEMA ensemble de vues avec la requête suivante:

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' 

Tout fonctionne parfaitement bien, mais pour une contrainte particulière, la valeur de UNIQUE_CONSTRAINT_NAME la colonne est fausse, et j'en ai besoin pour trouver des informations supplémentaires à partir de la colonne référencée. Fondamentalement, pour la plupart des lignes, le UNIQUE_CONSTRAINT_NAME contient le nom de la contrainte unique (ou PK) dans la table référencée, mais pour un FK particulier c'est le nom d'une autre contrainte unique. J'ai laissé tomber et recréé le FK - n'a pas aidé. Mon hypothèse est que les métadonnées sont vissées d'une manière ou d'une autre. Existe-t-il un moyen de reconstruire les métadonnées afin que les vues INFORMATION_SCHEMA affichent réellement les données correctes?

modifier-1: exemple de structure db

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 
) 

Je pense que le UNIQUE_CONSTRAINT_NAME d'être MY_PARENT_TABLE_PK, mais ce que je suis S'y rendre est MY_PARENT_TABLE_u_nci_ID_LongName. Après avoir examiné la structure, je vois qu'il y a 2 UNIQUE constantes sur cette colonne - PK et MY_PARENT_TABLE_u_nci_ID_LongName. Donc, la vraie question devrait probablement être: pourquoi prend-il un autre index unique et non le PK?

Answer 1

Étant donné que vous disposez d'une contrainte PK et UNIQUE sur la même colonne, SQL Server en choisit un à utiliser. Je ne sais pas si elle choisit la contrainte UNIQUE parce qu'elle est plus fine (moins de colonnes impliquées) et peut nécessiter moins de lectures pour confirmer les correspondances (?)

Je ne vois aucune façon dans SQL de l'appliquer choisit, autre que de commander vos scripts - créer la table avec le PK, créer l'autre table et le FK, puis créer la contrainte UNIQUE si vous en avez vraiment besoin - mais est-ce vraiment le cas?