sql >> Database >  >> RDS >> Sqlserver

Samengestelde primaire sleutel versus extra ID-kolom?

Zeg dat {Author, Title, Edition} een boek uniek identificeert, geldt het volgende:

  1. Het is een supersleutel -- identificeert op unieke wijze een tuple (rij).

  2. Het is onherleidbaar -- het verwijderen van een van de kolommen maakt het geen sleutel meer.

  3. Het is een kandidaatsleutel -- een onherleidbare supersleutel is een kandidaatsleutel.

Laten we nu eens kijken naar de ID (integer)

Ik kan redeneren dat het Book table key zal in weinig andere tabellen verschijnen als een externe sleutel en ook in enkele indexen. Het zal dus nogal wat ruimte in beslag nemen -- zeg drie kolommen x 40 tekens (of wat dan ook...) -- in elk van deze tabellen plus in overeenkomende indexen.

Om deze "andere" tabellen en indexen kleiner te maken, kan ik een unieke-integer-kolom toevoegen aan het Book tabel die moet worden gebruikt als een sleutel waarnaar wordt verwezen als een externe sleutel. Zeg iets als:

alter table Book add BookID integer not null identity;

Met BookID omdat het ook uniek is (moet zijn), is het Book tafel heeft nu twee kandidaatsleutels.

Nu kan ik de BookID . selecteren als primaire sleutel.

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

Echter, de {Author,Title,Edition} moeten blijf een sleutel (uniek) om voorkomen zoiets als dit:

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

Om het samen te vatten, het toevoegen van de BookID -- en het kiezen als de primaire -- stopte niet {Author, Title, Edition} een (kandidaat)sleutel zijn. Het moet nog steeds zijn eigen unieke beperking hebben en meestal de bijbehorende index.

Merk ook op dat vanaf het ontwerppunt deze beslissing op het "fysieke niveau" werd genomen. In het algemeen, op het logische niveau van ontwerp, deze ID bestaat niet -- het werd geïntroduceerd tijdens de overweging van kolomgroottes en indexen. Het fysieke schema is dus afgeleid van het logische. Afhankelijk van de DB-grootte, RDBMS en hardware die wordt gebruikt, heeft geen van die redeneringen over de grootte een meetbaar effect -- dus gebruik {Author, Title, Edition} aangezien een PK een perfect goed ontwerp kan zijn -- totdat het tegendeel bewezen is.



  1. SQUARE() Voorbeelden in SQL Server

  2. Prestatieverrassingen en veronderstellingen:GROUP BY vs. DISTINCT

  3. Mechanisme Gevolgd door Oracle wanneer we een hot-back-up maken

  4. SQL Server INFORMATION_SCHEMA Weergaven | Kijken of er een tafel bestaat