Förklarar vad en primärnyckel är och varför den är en integrerad del av relationsdatabaser.
När vi skapade våra två tabeller skapade vi också en primärnyckel för varje tabell.
När du expanderar noderna i den vänstra SCHEMAS fliken, kan du se primärnycklarna (och främmande nycklar – vi kommer till dem härnäst) listade under varje tabell:
Som den medföljande skärmdumpen visar, Index noder innehåller alla index (i vårt fall främmande nycklar och/eller primärnycklar). Dessa primärnycklar och främmande nycklar finns bara för att vi angav dem i vår kod när vi skapade tabellerna.
Specifikt använde vi PRIMARY KEY (FruitId) för att skapa
FruitId
kolumnen primärnyckeln för
Fruit
tabell, och vi använde PRIMARY KEY (UnitId) för att skapa
UnitId
kolumnen primärnyckeln för
Enheter
bord.
Vad är en primärnyckel?
En primär nyckel (även kallad en unik nyckel ) är en kolumn som har tilldelats som det unika identifierarfältet. Värdet i en primärnyckelkolumn är unikt för varje post. Med andra ord, inga två poster kan dela samma värde i den kolumnen.
Ett klassiskt exempel på ett primärnyckelfält är ett "ID"-fält. De flesta tabeller kommer att ha ett ID-fält som ger en unik identifierare för varje post. Exempel kan inkludera "CustomerId", "ProductId", "FruitId", etc. Utan ID-fält som dessa skulle din databas funktion vara allvarligt hämmad. Om du hade två eller flera kunder med samma namn, hur skulle du kunna hitta deras register? Även om det är sant att du möjligen kan hitta något unikt med varje post, är det mycket renare och lättare att ha en kolumn vars primära syfte är att ge en unik identifiering för varje post.
En primär burk kan antingen vara ett normalt värde som garanterat är unikt (ett ISBN-nummer för böcker, produktkod, etc), eller så kan det vara ett värde som genereras av applikationen eller DBMS specifikt för att vara unikt (som ett globalt unikt identifierare eller automatiskt ökande heltal).
Välja en primär nyckel
Var försiktig när du väljer en kolumn för din primärnyckel. Du måste se till att varje post kommer att ha en och att det inte finns någon möjlighet att två poster delar samma värde, eller att en post kommer att ha mer än ett värde.
Till exempel kan det fungera att använda användarens e-postadress i vissa fall, men det är inte en särskilt solid grund för en unik identifierare. Användare kan ändra sin e-postadress. Användare kan dela e-postadresser. Vissa användare kanske inte har en e-postadress. Naturligtvis kan du skriva ditt system för att hindra användare från att ändra sin e-postadress eller dela den, men ditt system skulle inte vara särskilt flexibelt eller användarvänligt.
Du kan kräva att alla användare har ett unikt användarnamn. Det skulle kunna fungera. Du måste dock tänka noga över alla möjligheter. Om det finns någon chans att användare kan ändra den eller dela den (förr, nutid eller framtid) använd den inte som en primärnyckel. Vad händer om "TechGuy12" avaktiverar sitt konto. Betyder det att en annan användare nu kan använda "TechGuy12"? Kommer det att vara ett problem för din applikation eller några rapporter du behöver generera?
Om du är osäker på det "unika" i ditt primära nyckelfält, använd ett automatiskt genererat nummer som ökar med varje post som skapas.