Une table Join (table d'association) possède-t-elle une clé primaire? relation plusieurs à plusieurs

Question

Une table de jointure (table d'association) a-t-elle une clé primaire? plusieurs à plusieurs relation. J'ai vu des tables Join avec une clé primaire et d'autres sans que quelqu'un puisse expliquer quand vous auriez une clé primaire dans une table de jointure et pourquoi?

Merci d'avance ;-)

Answer 1

Dans un pur « rejoindre » ou d'une table de jonction tous les champs feront partie de la clé primaire. Par exemple, nous allons examiner les tableaux suivants:

CREATE TABLE USERS 
    (ID_USER NUMBER PRIMARY KEY, 
    FIRST_NAME VARCHAR2(32), 
    LAST_NAME VARCHAR2(32)); 

CREATE TABLE ATTRIBUTES 
    (ID_ATTRIBUTE NUMBER PRIMARY KEY, 
    ATTRIBUTE_NAME VARCHAR2(64)); 

Une table de jonction entre ceux-ci pour permettre à plusieurs utilisateurs d'avoir beaucoup d'attributs seraient

CREATE TABLE USER_ATTRIBUTES 
    (ID_USER NUMBER REFERENCES USERS(ID_USER), 
    ID_ATTRIBUTE NUMBER REFERENCES ATTRIBUTES(ID_ATTRIBUTE), 
    PRIMARY KEY(ID_USER, ID_ATTRIBUTE)); 

Parfois, vous trouverez la nécessité d'ajouter un non-primaire colonne à une table de jonction, mais je trouve cela est relativement rare.

Partagez et appréciez.

Answer 2

Toutes les tables doivent avoir une clé primaire. :-)

Vous pouvez utiliser une clé étrangère composée ou une clé entière aveugle.

Vous utiliseriez la clé étrangère composée lorsqu'il n'y a aucun autre élément dans votre table d'association.

Vous pouvez utiliser la clé d'entier invisible lorsque la table d'association possède ses propres éléments. La clé étrangère composée serait définie avec deux index supplémentaires.

Answer 3

Cela dépend des enregistrements que vous associez. Vous pouvez créer une clé primaire composite sur les ID des enregistrements associés tant que vous n'avez pas besoin de plusieurs enregistrements par association.

Cependant, il est beaucoup plus important de vous assurer que ces deux colonnes sont indexées et que l'intégrité référentielle est définie.

Answer 4

Les tables de relations ont souvent trois clés de candidat, dont l'une n'a pas besoin d'être contrainte avec une contrainte, et le choix de la clé (le cas échéant) qui doit être «primaire» est arbitraire.

Considérons cet exemple de Joe Celko:

CREATE TABLE Couples 
(boy_name INTEGER NOT NULL UNIQUE -- nested key 
REFERENCES Boys (boy_name), 
girl_name INTEGER NOT NULL UNIQUE -- nested key, 
REFERENCES Girls(girl_name), 
PRIMARY KEY(boy_name, girl_name)); -- compound key 

"DUOS" tableau vous permet d'insérer ces lignes du jeu d'origine:

('Joe Celko', 'Brooke Shields') 
('Alec Baldwin', 'Kim Bassinger') 

Pensez à cette table pendant une minute. Le PRIMARY KEY est maintenant redondant. Si chaque garçon n'apparaît qu'une seule fois dans la table et que chaque fille n'apparaît qu'une fois dans le tableau, alors chaque paire (nom_du_brou, _nom_famille) ne peut apparaître qu'une seule fois.

D'un point de vue théorique, je pourrais laisser tomber la clé composée et faire soit boy_name ou girl_name la nouvelle clé primaire , ou je pourrais les laisser comme candidats clés.Les produits SQL et la théorie ne correspondent pas toujours à . Beaucoup de produits font l'hypothèse que le PRIMARY KEY est en une certaine façon spéciale dans le modèle de données et sera le moyen d'accéder à la table la plupart du temps.

... mais je pense que vous question est ce qui implique quelque chose comme, « En supposant que je suis le genre de personne qui fuit les clés naturelles en faveur des identifiants artificiels, devrais-je ajouter un identifiant artificiel à une table qui est composé entièrement d'identifiants artificiels référencés à partir d'autres tables? "