- Vad är nycklar?
- Enkla nycklar
- Konkatenerade eller sammansatta nycklar
- Primära nycklar
- Numrering och automatisk ökning
- Kan en tabell innehålla flera primärnycklar?
Medan många utvecklare och databasadministratörer kan arbeta med primary keys varje dag är det ett fascinerande ämne att fråga sig själv, "Vad exakt är en primary key och kan (eller bör) en databastabell innehålla flera primary keys samtidigt?”
Nedan kommer vi att undersöka dessa frågor mer i detalj och försöka komma fram till en rimlig och allmänt överenskommen konsensus inom utvecklingsgemenskapen.
Vad är nycklar?
För att förstå vad en primary key är i en databastabell måste vi först förstå lite om non-primary keys . En key i en tabell är helt enkelt ett attribut som används för att identifiera och komma åt den informationen. En tabell kan och kommer ofta att ha flera nycklar, till exempel i tabellen Users både email och username kan betraktas som nycklar.
Beroende på vilken utvecklare eller administratör du pratar med kan du höra om en mängd olika nyckeltyper och deras definitioner, så vi tar bara upp några olika exempel nedan och en grundläggande definition av var och en.
Enkla nycklar
En simple key är bara en nyckel som endast använder ett enda attribut i tabellen. Om vi inte inför fler begränsningar för nyckeln eller tabellen, då username attributet i exemplet ovan är en simple key .
Konkatenerade eller sammansatta nycklar
Taget ett steg längre från simple keys är concatenated eller compound nycklar. Som namnet antyder, en concatenated key är en sammanfogning av flera simple keys . Till exempel kan systemet automatiskt kombinera last_name och year_of_birth simple keys till en concatenated key , som så:smith1980 .
Primära nycklar
En [primary key](https://en.wikipedia.org/wiki/Unique_key) är en nyckel som har valts som huvudman (eller primär). ) representativt attribut för den dataraden. primary key är unikt och det attributet används sedan i hela databasen och nås och skickas till andra tabeller som representativt attribut för data i fråga.
I praktiken är primary key attribut är också markerat som NOT NULL i de flesta databaser, vilket innebär att attributet alltid måste innehålla ett värde för att posten ska infogas i tabellen.
Som ett exempel, antingen email eller username simple keys kunde tilldelas beteckningen för primary key , men vanligtvis är det bästa praxis att ställa in primary key till ett attribut som inte (eller kunde) ändras av vare sig affärslogiken eller till och med av individen. Föreställ dig till exempel en Users får en ny e-postadress, som sedan orsakar alla tidigare primary key associationer som gjorts med den gamla e-postadressen blir ogiltiga när den nya e-postadressen används.
Av denna anledning (bland annat), de flesta primary keys använd ett nummer eller en unik sträng, till exempel en [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) .
Numerering och automatisk ökning
Det är också kortfattat värt att notera att många databassystem är konfigurerade på ett sådant sätt att varje tabell har en primary key det är både numeriskt och även automatiskt inkrementerat. Detta betyder helt enkelt att databasmotorn själv automatiskt tilldelar varje ny post i den tabellen en unik primary key värde som är stegvis större än alla tidigare värden. De flesta utvecklare är dock överens om att denna praxis är inaktuell och avslöjar onödiga säkerhetsbrister för systemet när den används för vissa tabeller som representerar vissa data.
Föreställ dig till exempel alla Users poster tilldelas en auto-inkrementerad primary key värde, känt som id attribut. Om en illvillig person upptäcker att id attribut för en given användare (t.ex. John Smith) är värdet 1500 , detta avslöjar redan lite information. För det första indikerar det att det sannolikt finns minst minst 1499 andra användare i systemet, eller var det någon gång. Det betyder också att om John Smiths användarsida kan nås via en URL- eller API-anrop som innehåller det id värde på 1500 , då finns det en god chans att helt enkelt ändra värdet till ett annat nummer, till exempel 1499 eller 1501 , kommer att avslöja sidan för en annan användare som kanske inte vill att deras sida ska nås av denna besökare. På detta sätt kan poster efterfrågas genom att helt enkelt gissa id värden på en massskala.
Dessa är uppenbarligen mycket enkla exempel, men av dessa skäl kommer de flesta moderna databaser att använda en randomiserad och unik primary key attributvärde som en UUID när du arbetar med känsliga uppgifter.
Kan en tabell innehålla flera primärnycklar?
Det korta svaret är nej , en tabell får inte innehålla flera primary keys , eftersom det strider mot de grundläggande principerna för relationsdatabasdesign (se:[database normalisation](https://en.wikipedia.org/wiki/Database_normalisation) och [Third normal form](https://en.wikipedia.org/wiki/Third_normal_form) ).
Det är möjligt för en tabell att ha flera candidate keys , som faktiskt beter sig likt en primary key i att en candidate key är unik, NOT NULL , och är en singular representation av den tabellposten.
Men när det gäller att välja vilken ett attribut kommer att tilldelas som primary key för tabellen kommer valet från listan över alla potentiella candidate keys (därav namnet, de är kandidater för att bli en primary key ). I slutändan bara en candidate key väljs som det bästa representativa attributet för den posten, som ska användas i den här tabellen som primary key och refereras på andra ställen i databasen av andra tabeller via deras respektive foreign keys .