Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

Zusammengesetzter Primärschlüssel vs. zusätzliche ID-Spalte?

Sagen Sie, dass {Author, Title, Edition} ein Buch eindeutig identifiziert, dann gilt:

  1. Es ist ein Superschlüssel – identifiziert ein Tupel (Zeile) eindeutig.

  2. Es ist irreduzibel – das Entfernen einer der Spalten macht es nicht mehr zu einem Schlüssel.

  3. Es ist ein Kandidatenschlüssel – ein irreduzibler Superschlüssel ist ein Kandidatenschlüssel.

Betrachten wir nun die ID (Ganzzahl)

Ich kann mir vorstellen, dass das Book Der Tabellenschlüssel wird in wenigen anderen Tabellen als Fremdschlüssel und auch in wenigen Indizes angezeigt. Es wird also ziemlich viel Platz benötigen – sagen wir drei Spalten x 40 Zeichen (oder was auch immer …) – in jeder dieser Tabellen plus in passenden Indizes.

Um diese "anderen" Tabellen und Indizes kleiner zu machen, kann ich dem Book eine Unique-Integer-Spalte hinzufügen Tabelle, die als Schlüssel verwendet werden soll, auf die als Fremdschlüssel verwiesen wird. Sagen Sie so etwas wie:

alter table Book add BookID integer not null identity;

Mit BookID ebenfalls einmalig sein (muss), das Book Tabelle hat jetzt zwei Kandidatenschlüssel.

Jetzt kann ich die BookID auswählen als Primärschlüssel.

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

Der {Author,Title,Edition} müssen bleiben Sie ein Schlüssel (eindeutig), um vorzubeugen etwa so:

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

Um es zusammenzufassen, fügen Sie die BookID hinzu -- und es als primär auszuwählen -- hat {Author, Title, Edition} nicht gestoppt ein (Kandidaten-)Schlüssel sein. Es muss immer noch seine eigene eindeutige Einschränkung und normalerweise den passenden Index haben.

Beachten Sie auch, dass diese Entscheidung vom Design her auf der "physischen Ebene" getroffen wurde. Im Allgemeinen auf der logischen Designebene diese ID existiert nicht -- es wurde bei der Betrachtung von Spaltengrößen und Indizes eingeführt. Das physische Schema wurde also vom logischen abgeleitet. Abhängig von der DB-Größe, dem RDBMS und der verwendeten Hardware hat möglicherweise keine dieser Größenbetrachtungen einen messbaren Effekt – verwenden Sie also {Author, Title, Edition} als PK kann durchaus gutes Design sein -- bis das Gegenteil bewiesen ist.