web-dev-qa-db-fra.com

Clé primaire composite vs colonne "ID" supplémentaire?

Si nous avions une table comme celle-ci:

Livres (faire semblant que "ISBN" n'existe pas)

  • Auteur
  • Titre
  • Édition
  • Année de publication
  • Prix

On pourrait faire valoir que {Auteur, Titre, Édition} pourrait être un candidat/clé primaire.

Qu'est-ce qui détermine si la clé candidate/primaire doit être {Auteur, Titre, Édition} ou si une colonne ID doit être utilisée, avec {Auteur, Titre, Édition} une contrainte d'index/clé unique?

Tout comme

  • Auteur (PK)
  • Titre (PK)
  • Édition (PK)
  • Année de publication
  • Prix

mieux, ou:

  • ID (PK)
  • Auteur
  • Titre
  • Édition
  • Année de publication
  • Prix

où {Auteur, Titre, Édition} est un index/contrainte unique supplémentaire?

sqlsql-serverdatabasedatabase-design
42
user997112

Supposons que {Author,Title,Edition} Identifie de façon unique un livre, puis ce qui suit tient:

  1. Il s'agit d'une (super) clé - identifie de façon unique un tuple (ligne).

  2. Il est irréductible - la suppression de l'une des colonnes n'en fait plus une clé.

  3. Il s'agit d'une clé candidate - une clé irréductible est une clé candidate.

Considérons maintenant l'ID (entier)

Je peux penser que la clé de table Book apparaîtra dans quelques autres tables comme une clé étrangère et aussi dans quelques index. Ainsi, cela prendra un peu d'espace - disons trois colonnes x 40 caractères (ou peu importe ...) - dans chacune de ces tables plus dans les index correspondants.

Afin de rendre ces "autres" tables et index plus petits, je peux ajouter une colonne d'entier unique à la table Book à utiliser comme clé qui sera référencée comme clé étrangère. Dites quelque chose comme:

alter table `Book` add `BookID` integer not null identity;

Avec BookID étant (doit être) également unique, la table Book a maintenant deux clés candidates.

Maintenant, je peux sélectionner le BookID comme clé primaire.

alter table Book add constraint pk_Book primary key (BookID);

Cependant, le {Author,Title,Edition}doit rester une clé (unique) afin de empêcher quelque chose comme ceci:

BookID  Author      Title           Edition
----------------------------------------------- 
  1      C.J.Date  Database Design     1
  2      C.J.Date  Database Design     1

Pour résumer, l'ajout de BookID - et le choix comme primaire - n'a pas empêché {Author,Title,Edition} D'être une clé (candidate). Il doit toujours avoir sa propre contrainte unique et généralement l'index correspondant.

Notez également que du point de vue de la conception, cette décision a été prise au "niveau physique". En général, au niveau logique de la conception, ce ID n'existe pas - il a été introduit lors de l'examen des tailles de colonne et des index. Le schéma physique était donc dérivé du schéma logique. Selon la taille de la base de données, le SGBDR et le matériel utilisé, aucun de ces raisonnements de taille peut avoir un effet mesurable - donc l'utilisation de {Author,Title,Edition} Comme PK peut être parfaitement bien conçue - jusqu'à preuve du contraire.

40
Damir Sudarevic

En général, vous ne voulez pas que la clé primaire change de valeur. C'est pourquoi des clés primaires aveugles ou de substitution sont utilisées.

Supposons que vous ayez créé votre table Book avec Author dans le cadre de la clé primaire.

Supposons que vous ayez découvert après environ un an que vous avez mal orthographié "Ray Bradbury". Ou pire encore, vous avez mal orthographié "Rachael Bloom". Imaginez simplement combien de lignes de base de données vous devriez modifier pour corriger l'orthographe. Imaginez simplement combien de références d'index doivent être modifiées.

Cependant, si vous avez une table Author avec une clé de substitution, vous n'avez qu'à corriger une ligne. Aucun index ne doit être modifié.

Enfin, les noms de table de base de données sont généralement au singulier (Livre) plutôt qu'au pluriel (Livres).

15
Gilbert Le Blanc

Une autre bonne raison d'utiliser le scénario de clé primaire de substitution est de savoir si la contrainte d'unicité devrait changer à l'avenir (par exemple, l'ISBN doit être ajouté pour rendre un livre unique). La recomposition de vos données sera beaucoup plus facile.

7
Scotty Boy

Il existe de nombreux articles à ce sujet. Les problèmes avec la clé composite dans votre cas:

  1. difficile de lier des livres avec d'autres entités
  2. Difficile de les modifier dans une grille car la plupart des grilles ne prennent pas en charge les clés composites (par exemple la grille de kendo, jqgrid)
  3. Vous pourriez mal orthographier l'auteur, le titre, l'édition

Il serait également bon de normaliser vos données et de stocker juste un ID à l'auteur comme (dasblinkenlight) suggéré. Dans le pire des cas, il/elle changera son nom (par exemple, elle se marie et elle aime son nouveau nom).

4
Petrutiu Mihai