Pourquoi utiliser plusieurs colonnes de clés primaires (clé primaire composite)
cet exemple est tiré de 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)
)
ma compréhension est que les deux colonnes ensemble ( P_Id et LastName ) représentent une clé primaire pour le tableau 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 une clé primaire dans un compte tenu de table?
8 réponses
Votre compréhension est correcte.
vous feriez cela dans de nombreux cas. Un exemple est dans une relation comme OrderHeader et OrderDetail . Le PK dans OrderHeader pourrait être OrderNumber . Le PK dans OrderDetail pourrait être OrderNumber et LineNumber . Si c'était l'une de ces deux, il ne serait pas unique, mais la combinaison des deux est garanti unique.
l'alternative est d'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 une façon, d'autres préfèrent l'autre.
un autre exemple de clés primaires composées est l'utilisation de tables D'Association. Supposons que vous avez une table qui contient un ensemble de personnes et une table de groupe qui contient un ensemble de groupes. Maintenant, vous voulez créer une relation beaucoup à beaucoup sur la personne et le 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))
L'exemple de W3Schools ne dit pas quand vous devez utiliser les clés primaires composées, et ne donne que la syntaxe d'exemple en utilisant la même table d'exemple que pour les autres clés.
leur choix d'exemple vous induit peut-être en erreur 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 un élève de façon unique. Intuitivement, cela ne fait pas sens.
1234 Jobs
1234 Gates
en savoir plus: le grand débat primaire-clé ou tout simplement Google meaningless primary keys ou même lire ce ainsi question
FWIW - Mes 2 centimes, c'est pour éviter le multi-colonnes clés primaires et l'utilisation d'un unique généré champ id (clé de substitution) en tant que clé primaire et à l'ajout de (unique) des contraintes, si nécessaire.
Oui, ils forment tous les deux la clé primaire. En particulier dans les tables où vous n'avez pas de clé de remplacement , il peut être nécessaire de spécifier plusieurs attributs comme Identificateur unique pour chaque enregistrement (mauvais exemple: une table avec à la fois un prénom et un nom de famille peut exiger que la combinaison d'eux d'être unique).
plusieurs colonnes dans une clé vont, en général, fonctionner plus mal qu'une clé de substitution. Je préfère avoir une clé de substitution et puis un index unique sur une clé multicolonne. De cette façon, vous pouvez avoir de meilleures performances et l'unicité nécessaire est maintenu. Et encore mieux, lorsque l'une des valeurs de cette clé change, vous n'avez pas à mettre à jour un million d'entrées enfant dans 215 tables enfant.
vous utilisez une clé composée (une clé avec plus d'un attribut) chaque fois que vous voulez assurer l'unicité d'une combinaison de plusieurs attributs. Une clé à attribut unique n'obtiendrait pas le même résultat.
votre deuxième partie question
combien de colonnes peuvent être utilisées ensemble comme clé primaire dans un tableau donné?
est spécifique à la mise en œuvre: 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. Rechercher sur le web au sujet d'une telle limitation peut être difficile parce que la terminologie varier. Le terme clé primaire composite devrait être rendue obligatoire ;)
si vous ne trouvez pas d'informations explicites, essayez avec une base de données de test pour vous assurer que vous pouvez vous attendre à un traitement stable (et spécifique) de la violation des limites (qui sont raisonnablement à prévoir). Faites attention à obtenir les bonnes informations à ce sujet: parfois les limites sont accumulées, et vous verrez différents résultats avec différentes mises en page de la base de données.
utiliser une clé primaire sur plusieurs tables est pratique lorsque vous utilisez une table intermédiaire dans une base de données relationnelle.
je vais utiliser une base de données que j'ai fait une fois pour un exemple et spécifiquement trois tables dans cette table. J'ai créé une base de données pour un webcomic il y a quelques années. Une table a été appelée "comics"-une liste de tous les comics, leurs titres, le nom de fichier image, etc. La clé principale était "comicnum".
le deuxième tableau était "personnages" -leurs noms et une brève description. La clé principale était sur "charname".
comme chaque bande dessinée-à quelques exceptions près-avait plusieurs caractères et que chaque caractère apparaissait dans plusieurs bandes dessinées, il n'était pas pratique de mettre une colonne dans" caractères "ou" bandes dessinées " pour refléter cela. Au lieu de cela, j'ai créé un troisième table a été appelé "comicchars", et c'était une liste de caractères qui sont apparus dans les comics. Puisque ce tableau essentiellement joint les deux tables, il n'avait besoin que de deux colonnes: charname et comicnum, et la clé primaire était sur les deux.