Pourquoi les clés primaires composites existent-elles encore ?

Question

Je suis chargé de migrer une base de données vers un ERP de classe moyenne. Le nouveau système utilise des clés primaires composites ici et là, et d'un point de vue pragmatique, pourquoi ?

Par rapport aux identifiants générés automatiquement, je ne vois que des aspects négatifs ;

• Les clés étrangères deviennent floues
• Migration plus difficile ou refonte de la base de données
• Inflexible face à l'évolution des affaires. (Ma voiture n'a pas de plaque d'immatriculation )
• La même intégrité est mieux obtenue avec des contraintes.

C'est retomber dans le concept des clés de candiature, dont je ne vois pas l'intérêt.

Est-ce une habitude/un artefact du temps des disquettes (minimiser l'espace/index), ou est-ce que je rate quelque chose ?

//edit// Je viens de trouver un bon poste SO : Clés primaires composites et champ d'identification unique de l'objet //

Answer 1

Les clés composites sont nécessaires lorsque vos clés primaires sont non substitutives et intrinsèquement composites, c'est-à-dire qu'elles peuvent être décomposées en plusieurs parties non liées.

Quelques exemples concrets :

• Tables de liens multiples, dans lesquelles les clés primaires sont composées des clés des entités liées.

• Applications multi-locataires lorsque tenant_id fait partie de la clé primaire de chaque entité et les entités ne peuvent être liées qu'au sein d'un même locataire (contrainte par une clé étrangère).

• Applications traitant des données de tiers (avec des clés primaires déjà fournies)

Notez que, logiquement, tout ceci peut être réalisé en utilisant un UNIQUE (en plus d'une contrainte de substitution PRIMARY KEY ).

Cependant, il y a quelques éléments spécifiques à la mise en œuvre :

• Certains systèmes ne permettent pas à un FOREIGN KEY se réfère à tout ce qui n'est pas un PRIMARY KEY .

• Certains systèmes ne regroupent une table que sur un PRIMARY KEY ce qui fait que le composite est le PRIMARY KEY améliorerait les performances des requêtes se joignant sur le composite.

Answer 2

Clé primaire composite offre de meilleures performances lorsqu'il s'agit de les utiliser comme clés étrangères dans d'autres tables, et réduit la table de lecture - Parfois, ils peuvent être des sauveurs de vie. Si vous utilisez des clés de substitution, vous devez vous rendre dans cette table pour obtenir des informations sur les clés naturelles.

Par exemple (un pur exemple - nous ne parlons pas de conception de BD ici), disons que vous avez une ORDER table et ORDER_ITEM . Si vous utilisez ProductId y LineNumber ( UPDATE : et comme Pedro l'a mentionné OrderId ou mieux encore OrderNumber ) comme clé primaire composite dans ORDER_ITEM puis dans votre tableau croisé pour SHIPPING vous pourriez avoir le ProductId dans le champ SHIPPING_ORDERITEM . Cela peut améliorer considérablement vos performances si, par exemple, vous êtes en rupture de stock d'un produit et que vous devez trouver tous les produits de ce produit. ProductId qui doivent être expédiés sans qu'il soit nécessaire de les joindre.

D'autre part, si vous utilisez une clé de substitution, vous devez faire une jointure et vous vous retrouvez avec un plan d'exécution SQL très inefficace où il faut faire recherche de signets sur plusieurs index.

Ver plus sur recherche de signets l'utilisation de clés de substitution devient un problème majeur.

Answer 3

Personnellement, je préfère l'utilisation de clés de substitution. Cependant, pour joindre des tables qui ne sont constituées que des identifiants de deux autres tables (pour créer des relations multiples), les clés composites sont la solution et leur suppression rendrait les choses plus difficiles.

Il existe une école de pensée selon laquelle les clés de substitution sont toujours mauvaises et que si vous n'avez pas d'unicité à enregistrer grâce à l'utilisation de clés naturelles, votre conception est mauvaise. Je ne suis pas du tout d'accord avec cela (si vous ne stockez pas le SSN ou une autre valeur unique, je vous défie de trouver une clé naturelle pour une table de personnes par exemple). Mais beaucoup de gens pensent que c'est nécessaire pour une normalisation correcte.

Parfois, le fait de disposer d'une clé composite réduit la nécessité d'une jointure à une autre table. Parfois, ce n'est pas le cas. Il y a donc des moments où une clé composite peut améliorer les performances, mais aussi des moments où elle peut nuire aux performances. Si la clé est relativement stable, vous pouvez vous contenter de performances plus rapides sur les requêtes de sélection. Cependant, s'il s'agit d'un élément susceptible de changer, comme le nom d'une société, vous risquez d'avoir de gros ennuis si la société A change de nom et que vous devez mettre à jour un million d'enregistrements associés.

Il n'existe pas de solution unique pour la conception de bases de données. Il y a des moments où les clés composites sont utiles et d'autres où elles sont horribles. Il y a des moments où les clés de substitution sont utiles et d'autres où elles ne le sont pas.

Answer 4

Les clés primaires naturelles sont fragiles.

Supposons que nous ayons construit un système autour d'un PK naturel sur (CountryCode, PhoneNumber), et que plusieurs années plus tard, nous ayons besoin d'ajouter une extension, ou de changer le PK en une seule colonne : Email. Si ces colonnes PK sont propagées à toutes les tables filles, cela devient très coûteux.

Il y a quelques années, certains systèmes ont été construits en partant du principe que le numéro de sécurité sociale était une PC naturelle, et ont dû être reconçus pour utiliser des identités, lorsque le SSN est devenu non unique et annulable.

Comme nous ne pouvons pas prédire l'avenir, nous ne savons pas si, plus tard, un changement rendra obsolète ce qui était un modèle parfaitement correct et complet.

Answer 5

La réponse très simple est l'intégrité des données. Si les données doivent être utiles et précises, les clés sont vraisemblablement nécessaires. Le fait de disposer d'un "identifiant autogénéré" ne supprime pas la nécessité de disposer également d'autres clés. L'autre solution consiste à ne pas imposer l'unicité et à accepter que les données soient dupliquées et contiennent presque inévitablement des anomalies, ce qui entraîne des erreurs. Pourquoi voulez-vous cela ?