Pourquoi utiliser plusieurs colonnes comme clés primaires (clé primaire composite)

109

Cet exemple est tiré de w3schools .

CREATE TABLE Persons
(
    P_Id int NOT NULL,
    LastName varchar(255) NOT NULL,
    FirstName varchar(255),
    Address varchar(255),
    City varchar(255),
    CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
)

Je crois comprendre que les deux colonnes ensemble ( P_Idet LastName) représentent une clé primaire pour la table Persons. Est-ce correct?

Pourquoi quelqu'un voudrait-il utiliser plusieurs colonnes comme clés primaires au lieu d'une seule colonne?
Combien de colonnes peuvent être utilisées ensemble comme clé primaire dans une table donnée?

— rockbala
source

... maintenant il y a aussi une réponse à la 2ème question

— Wolf

1

@Martijn Peters. Pourquoi la réponse a-t-elle été supprimée?

— PerformanceDBA

119

Votre compréhension est correcte.

Vous feriez cela dans de nombreux cas. Un exemple est dans une relation comme OrderHeaderet OrderDetail. Le PK OrderHeaderpourrait être OrderNumber. Le PK dans OrderDetailpourrait être OrderNumberAND LineNumber. S'il s'agissait de l'un de ces deux, ce ne serait pas unique, mais la combinaison des deux est garantie unique.

L'alternative consiste à utiliser une clé primaire générée (non intelligente), par exemple dans ce cas OrderDetailId. Mais alors, vous ne verriez pas toujours la relation aussi facilement. Certaines personnes préfèrent un sens; certains préfèrent l'autre manière.

— MJB
source

2

Est-ce utile si j'utilise branch_id et que j'utilise la réplication entre deux bases de données, résoudra les doublons d'ID? !!

— Mhmd

11

Notez que dans de nombreux cas d'utilisation d'une clé primaire générée, vous souhaitez souvent toujours une clé unique sur les valeurs composites.

— Bacon Bits

Veuillez préciser "Certaines personnes préfèrent un moyen, d'autres préfèrent l'autre".

— Nom d'utilisateur

1

Veuillez élaborer? Ne sais pas quoi dire. J'ai connu des gens qui préfèrent avoir plusieurs champs concaténés comme clé car il est plus facile de comprendre intuitivement ce qu'ils regardent. J'en connais d'autres qui préfèrent simplement attribuer une clé unique à chaque ligne car il est plus facile et plus rapide à taper. C'est ce que vous demandez?

— MJB

Ce message était destiné à @Username. J'ai oublié de le diriger.

— MJB

26

Un autre exemple de clés primaires composées est l'utilisation des tables d'association. Supposons que vous ayez une table de personnes contenant un ensemble de personnes et une table de groupes contenant un ensemble de groupes. Vous voulez maintenant créer une relation plusieurs à plusieurs sur une personne et un groupe. Cela signifie que chaque personne peut appartenir à de nombreux groupes. Voici à quoi ressemblerait la structure de la table en utilisant une clé primaire composée.

Create Table Person(
PersonID int Not Null,
FirstName varchar(50),
LastName varchar(50),
Constraint PK_Person PRIMARY KEY (PersonID))

Create Table Group (
GroupId int Not Null,
GroupName varchar(50),
Constraint PK_Group PRIMARY KEY (GroupId))

Create Table GroupMember (
GroupId int Not Null,
PersonId int Not Null,
CONSTRAINT FK_GroupMember_Group FOREIGN KEY (GroupId) References Group(GroupId),
CONSTRAINT FK_GroupMember_Person FOREIGN KEY (PersonId) References Person(PersonId),
CONSTRAINT PK_GroupMember PRIMARY KEY (GroupId, PersonID))

— John Hartsock
source

bonne explication: je pense que le besoin d'attributs pour les relations m-à-n (dans une fasion normalisée) est la clé.

— Wolf

peut-être ajouter une petite explication des avantages serait encore mieux

— Martian2049

10

L'exemple W3Schools ne dit pas quand vous devez utiliser des clés primaires composées et ne donne qu'un exemple de syntaxe en utilisant le même exemple de tableau que pour les autres clés.

Leur choix d'exemple vous trompe peut-être en combinant une clé sans signification (P_Id) et une clé naturelle (LastName). Ce choix étrange de clé primaire indique que les lignes suivantes sont valides selon le schéma et sont nécessaires pour identifier de manière unique un étudiant. Intuitivement, cela n'a aucun sens.

1234     Jobs
1234     Gates

Lectures complémentaires: Le grand débat sur la clé primaire ou simplement Google meaningless primary keysou même parcourez ceci question SO

FWIW - Mon 2 centimes est d'éviter les clés primaires multi-colonnes et d'utiliser un seul champ d'identifiant généré (clé de substitution) comme clé primaire et d'ajouter des contraintes (uniques) supplémentaires si nécessaire.

— Robert Paulson
source

1

1) le lien «grand débat sur la clé primaire» est particulièrement stupide, l'information est égoïste et fausse. 2) L'index sur les colonnes qui rendent la ligne unique ne peut être évité. Un ID «de substitution» avec un index est toujours une colonne supplémentaire et un index supplémentaire. Plutôt idiot car redondant. Et plus lentement.

— PerformanceDBA

2

Le "grand débat sur la clé primaire" n'est pas stupide. C'est un problème très valable de la part des développeurs qui ne sont pas des développeurs SQL ou des DBA SQL et qui ne passent pas tout leur temps dans SQL. Même en SQL pur, je préfère avoir une clé auto-générée sans signification comme clé primaire lors de la jointure que de ne pas oublier de passer n bits de données autour de la clé naturelle. Vous êtes les bienvenus dans votre point de vue, mais nous apprécierions de ne pas être aussi dédaigneux.

— Robert Paulson

4

Vous utilisez une clé composée (une clé avec plus d'un attribut) chaque fois que vous souhaitez garantir l'unicité d'une combinaison de plusieurs attributs. Une seule clé d'attribut ne permettrait pas d'obtenir la même chose.

— nvogel
source

1

En ce qui concerne la garantie d'une clé unique, vous pouvez compter sur la combinaison de deux attributs pour former une clé qui ne peut logiquement pas être dupliquée, la personne et la date d'obtention du diplôme d'un ensemble de données plus grand en seraient un exemple.

— John Mark

3

Oui, ils forment tous les deux la clé primaire. Surtout dans les tables où vous n'avez pas de clé de substitution , il peut être nécessaire de spécifier plusieurs attributs comme identifiant unique pour chaque enregistrement (mauvais exemple: une table avec à la fois un prénom et un nom de famille peut exiger que leur combinaison soit unique).

— ig0774
source

3

En général, plusieurs colonnes dans une clé seront moins performantes qu'une clé de substitution. Je préfère avoir une clé de substitution puis un index unique sur une clé multicolonne. De cette façon, vous pouvez avoir de meilleures performances et l'unicité nécessaire est maintenue. Et encore mieux, lorsque l'une des valeurs de cette clé change, vous n'avez pas non plus à mettre à jour un million d'entrées enfants dans 215 tables enfants.

— HLGEM
source

1

1) Performance. Pas dans une plate-forme SQL (peut-être dans les prétendus "sql" et freeware). 2) La préférence n'est pas pertinente. Ce que les tableaux exigent, pour l'intégrité, est pertinent. 3) Un ID «de substitution» avec un index est toujours une colonne supplémentaire et un index supplémentaire . Ce serait donc plus lent, quelle que soit la plateforme. Re performance, vous vous contredisez. 4) Si vous ne savez pas comment mettre à jour correctement le mythique "million d'entrées enfants dans 215 tables enfants" , posez une question.

— PerformanceDBA

2

Je ne suis pas d'accord avec l'affirmation «Plusieurs colonnes dans une clé vont, en général, avoir de moins bons résultats qu'une clé de substitution». Une requête supplémentaire est souvent nécessaire pour obtenir la clé de substitution d'une relation lorsque vous la considérez. À quel point c'est un aller-retour complet plus lent en termes de performances.

— ttugates le

3

Votre deuxième question

Combien de colonnes peuvent être utilisées ensemble comme clé primaire dans une table donnée?

est spécifique à l'implémentation: il est défini dans le SGBD réel utilisé. ^{[1], [2], [3]} Vous devez inspecter les spécifications techniques du système de base de données que vous utilisez. Certains sont très détaillés, d'autres non. La recherche sur le Web à propos de telles limitations peut être difficile car la terminologie varie. Le terme clé primaire composite doit être obligatoire;)

Si vous ne trouvez pas d'informations explicites, essayez de créer une base de données de test pour vous assurer que vous pouvez vous attendre à une gestion stable (et spécifique) des violations de limites (auxquelles il faut s'attendre). Faites attention à obtenir les bonnes informations à ce sujet: parfois, les limites sont accumulées et vous verrez des résultats différents avec différentes dispositions de base de données.

— Loup
source

2

L'utilisation d'une clé primaire sur plusieurs tables est pratique lorsque vous utilisez une table intermédiaire dans une base de données relationnelle.

J'utiliserai une base de données que j'ai créée une fois pour un exemple et en particulier trois tables dans cette table. J'ai créé une base de données pour une bande dessinée il y a quelques années. Une table s'appelait «bandes dessinées» - une liste de toutes les bandes dessinées, leurs titres, le nom du fichier image, etc. La clé primaire était «comicnum».

Le deuxième tableau était «caractères» - leurs noms et une brève description. La clé primaire était sur "charname".

Étant donné que chaque bande dessinée - à quelques exceptions près - avait plusieurs personnages et que chaque personnage apparaissait dans plusieurs bandes dessinées, il était impossible de mettre une colonne dans «personnages» ou «bandes dessinées» pour refléter cela. Au lieu de cela, j'ai créé une troisième table qui s'appelait "comicchars", et c'était une liste des personnages apparaissant dans quelles bandes dessinées. Comme cette table rejoignait essentiellement les deux tables, elle n'avait besoin que de deux colonnes: charname et comicnum, et la clé primaire était sur les deux.

— M. Initial Man
source

1

Nous créons des clés primaires composites pour garantir l'unicité des valeurs de colonne qui composent un seul enregistrement. C'est une contrainte qui permet d'éviter l'insertion de données qui ne doivent pas être dupliquées.

Par exemple: si tous les identifiants d'étudiant et les numéros de certificat de naissance sont attribués de manière unique à une seule personne. Ensuite, ce serait une bonne idée de faire de la clé primaire d'une personne une composition d'identifiant d'étudiant et de numéro d'acte de naissance, car cela vous éviterait d'insérer accidentellement deux personnes qui ont des identifiants d'étudiant différents et le même certificat de naissance.

— kiwicomb123
source