Selvom dit brugernavn er unikt, er der få fordele ved at have en ekstra id-kolonne i stedet for at bruge varchar som din primære nøgle.
-
Nogle mennesker foretrækker at bruge en heltalskolonne som den primære nøgle, for at fungere som en surrogatnøgle, der aldrig behøver at ændre sig, selvom andre kolonner kan ændres. Selvom der ikke er noget, der forhindrer, at en naturlig primær nøgle også kan ændres, skal du bruge kaskadende fremmednøglebegrænsninger for at sikre, at fremmednøglerne i relaterede tabeller opdateres synkroniseret med en sådan ændring.
-
Den primære nøgle er et 32-bit heltal i stedet for en varchar kan spare plads. Valget mellem en int eller en varchar fremmednøglekolonne i hver anden tabel, der refererer til din brugertabel, kan være en god grund.
-
Indsættelse til det primære nøgleindeks er en smule mere effektivt, hvis du tilføjer nye rækker til slutningen af indekset, sammenlignet med at kile dem ind i midten af indekset. Indekser i MySQL-tabeller er normalt B+Tree-datastrukturer, og du kan studere disse for at forstå, hvordan de fungerer.
-
Nogle applikationsrammer foretrækker den konvention, at hver tabel i din database har en primær nøglekolonne kaldet
id, i stedet for at bruge naturlige nøgler eller sammensatte nøgler. At følge sådanne konventioner kan gøre visse programmeringsopgaver enklere.
Ingen af disse problemer er deal-breakers. Og der er også fordele ved at bruge naturlige nøgler:
-
Hvis du oftere slår rækker op efter brugernavn, end du søger på id, kan det være bedre at vælge brugernavnet som primær nøgle, og drage fordel af den indeksorganiserede lagring af InnoDB. Gør din primære opslagskolonne til den primære nøgle, hvis det er muligt, fordi primærnøgleopslag er mere effektive i InnoDB (du bør bruge InnoDB i MySQL).
-
Som du har bemærket, hvis du allerede har en unik begrænsning på brugernavnet, virker det som spild af lagerplads at beholde en ekstra id-kolonne, du ikke har brug for.
-
Brug af en naturlig nøgle betyder, at fremmednøgler indeholder en værdi, der kan læses af mennesker, i stedet for et vilkårligt heltals-id. Dette gør det muligt for forespørgsler at bruge fremmednøgleværdien uden at skulle slutte sig tilbage til den overordnede tabel for den "rigtige" værdi.
Pointen er, at der ikke er nogen regel, der dækker 100 % af tilfældene. Jeg anbefaler ofte, at du holder dine muligheder åbne og bruger naturlige nøgler, sammensatte nøgler og surrogatnøgler selv i en enkelt database.
Jeg dækker nogle problemer med surrogatnøgler i kapitlet "ID påkrævet" i min bog SQL-antimønstre:undgåelse faldgruberne ved databaseprogrammering .