Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Clé primaire composite vs colonne ID supplémentaire ?

Dites que {Author, Title, Edition} identifie de manière unique un livre, alors ce qui suit est valable :

  1. C'est une super-clé - identifie de manière unique un tuple (ligne).

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

  3. C'est une clé candidate -- une super-clé irréductible est une clé candidate.

Considérons maintenant l'ID (entier)

Je peux raisonner que le Book La clé de table apparaîtra dans quelques autres tables en tant que clé étrangère et également dans quelques index. Donc, cela prendra pas mal d'espace - disons trois colonnes x 40 caractères (ou autre...) - dans chacune de ces tables plus dans les index correspondants.

Afin de réduire la taille de ces "autres" tables et index, je peux ajouter une colonne d'entier unique au Book table à 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) unique aussi, le Book la table 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 d'empêcher quelque chose comme ça :

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

Pour résumer, ajouter le BookID -- et en le choisissant comme principal -- n'a pas arrêté {Author, Title, Edition} être une clé (candidat). 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 sur le "niveau physique". En général, au niveau logique de conception, cet ID n'existe pas - il a été introduit lors de l'examen des tailles de colonne et des index. Ainsi, le schéma physique a été dérivé du schéma logique. En fonction de la taille de la base de données, du RDBMS et du matériel utilisé, aucun de ces raisonnements sur la taille ne peut avoir d'effet mesurable -- donc en utilisant {Author, Title, Edition} car un PK peut être parfaitement bien conçu - jusqu'à preuve du contraire.