- Hvad er nøgler?
- Enkle nøgler
- Sammenkædede eller sammensatte nøgler
- Primære nøgler
- Nummerering og automatisk stigning
- Kan en tabel indeholde flere primære nøgler?
Mens mange udviklere og databaseadministratorer kan arbejde med primary keys Hver dag er det et fascinerende emne at spørge sig selv:"Hvad er det præcist er en primary key og kan (eller bør) en databasetabel indeholde flere primary keys samtidigt?”
Nedenfor vil vi undersøge disse spørgsmål mere detaljeret og forsøge at nå frem til den rimelige og generelt aftalte konsensus i udviklingssamfundet.
Hvad er nøgler?
For at forstå, hvad en primary key er i en databasetabel, skal vi først forstå lidt om non-primary keys . En key i en tabel er simpelthen en egenskab, der bruges til at identificere og få adgang til disse oplysninger. En tabel kan og vil ofte have flere nøgler, f.eks. i tabellen Users både email og username kunne betragtes som nøgler.
Afhængigt af den udvikler eller administrator, du taler med, kan du høre om en række forskellige nøgletyper og deres definitioner, så vi vil blot dække et par forskellige eksempler nedenfor og en grundlæggende definition af hver.
Simple nøgler
En simple key er kun en nøgle, der kun bruger én enkelt attribut i tabellen. Medmindre vi lægger flere begrænsninger på nøglen eller tabellen, så username attributten i ovenstående eksempel er en simple key .
Konkatenerede eller sammensatte nøgler
Taget et skridt videre fra simple keys er concatenated eller compound nøgler. Som navnet antyder, en concatenated key er en sammenføjning af flere single keys . For eksempel kan systemet automatisk kombinere last_name og year_of_birth single keys ind i en concatenated key , som sådan:smith1980 .
Primære nøgler
En [primary key](https://en.wikipedia.org/wiki/Unique_key) er en nøgle, som er blevet valgt til at være den primære (eller primære). ) repræsentativ attribut for denne række af data. Den primary key er unik og den attribut bruges derefter i hele databasen og tilgås og videregives til andre tabeller som den repræsentative attribut for de pågældende data.
I praksis er den primary key attribut er også markeret som NOT NULL i de fleste databaser, hvilket betyder, at attributten altid skal indeholde en værdi, for at posten kan indsættes i tabellen.
Som et eksempel, enten email eller username simple keys kunne blive tildelt betegnelsen primary key , men typisk er det bedste praksis at indstille den primary key til en egenskab, der ikke er (eller ikke kunne) ændres af hverken forretningslogikken eller endda af individet. Forestil dig f.eks. en User får en ny e-mailadresse, som så forårsager alle tidligere primary keys tilknytninger, der er lavet ved hjælp af den gamle e-mailadresse, bliver ugyldige, når du bruger den nye e-mailadresse.
Af denne grund (blandt andre), de fleste primary keys brug et tal eller en unik streng, såsom en [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) .
Nummerering og automatisk stigning
Det er også kort værd at bemærke, at mange databasesystemer er sat op på en sådan måde, at hver tabel har en primary key det er både numerisk og er også auto-inkrementeret. Dette betyder ganske enkelt, at databasemotoren selv automatisk tildeler hver ny post i den tabel en unik primary key værdi, der er trinvist større end alle tidligere værdier. De fleste udviklere er dog enige om, at denne praksis er forældet og afslører unødvendige sikkerhedsfejl for systemet, når det bruges til nogle tabeller, der repræsenterer bestemte data.
Forestil dig f.eks. alle User poster tildeles en auto-inkrementeret primary key værdi, kendt som id attribut. Hvis en ondsindet person opdager, at id attribut for en given bruger (f.eks. John Smith) er værdien 1500 , dette afslører allerede en smule information. For det første indikerer det, at der sandsynligvis er mindst 1499 andre brugere i systemet, eller var det på et tidspunkt. Det betyder også, at hvis John Smiths brugerside kan tilgås via et URL- eller API-kald, som indeholder det id værdi på 1500 , så er der en god chance for blot at ændre værdien til et andet tal, såsom 1499 eller 1501 , vil afsløre siden for en anden bruger, som muligvis ikke ønsker at få adgang til deres side af denne besøgende. På denne måde kan poster forespørges ved blot at gætte id værdier på en masseskala.
Disse er naturligvis meget simple eksempler, men af disse grunde vil de fleste moderne databaser bruge en randomiseret og unik primary key attributværdi såsom en UUID når du arbejder med følsomme data.
Kan en tabel indeholde flere primære nøgler?
Det korte svar er nej , en tabel må ikke indeholde flere primary keys , da det strider imod de grundlæggende principper for relationel databasedesign (se:[database normalisation](https://en.wikipedia.org/wiki/Database_normalisation) og [Third normal form](https://en.wikipedia.org/wiki/Third_normal_form) ).
Det er muligt for en tabel at have flere candidate keys , som effektivt opfører sig som en primary key i at en candidate key er unik, NOT NULL , og er en enestående repræsentation af denne tabelpost.
Men når det kommer til at vælge hvilken en attribut vil blive tildelt som den primary key for tabellen kommer valget fra listen over alle potentielle candidate keys (deraf navnet, de er kandidater til at blive en primary key ). I sidste ende kun én candidate key er valgt som den bedste repræsentative attribut for denne post, der skal bruges i denne tabel som primary key og refereret andre steder i databasen af andre tabeller via deres respektive foreign keys .