Även om ditt användarnamn är unikt, finns det få fördelar med att ha en extra id-kolumn istället för att använda varchar som din primära nyckel.
-
Vissa människor föredrar att använda en heltalskolumn som primärnyckel, för att fungera som en surrogatnyckel som aldrig behöver ändras, även om andra kolumner kan ändras. Även om det inte finns något som hindrar att en naturlig primärnyckel också kan ändras, måste du använda kaskadbegränsningar för främmande nyckel för att säkerställa att de främmande nycklarna i relaterade tabeller uppdateras synkroniserat med sådana ändringar.
-
Primärnyckeln är ett 32-bitars heltal istället för en varchar kan spara utrymme. Valet mellan en int eller en varchar främmande nyckelkolumn i varannan tabell som refererar till din användartabell kan vara ett bra skäl.
-
Att infoga i det primära nyckelindexet är lite mer effektivt om du lägger till nya rader i slutet av indexet, jämfört med att kila in dem i mitten av indexet. Index i MySQL-tabeller är vanligtvis B+Tree-datastrukturer, och du kan studera dessa för att förstå hur de fungerar.
-
Vissa applikationsramverk föredrar konventionen att varje tabell i din databas har en primärnyckelkolumn som heter
id, istället för att använda naturliga nycklar eller sammansatta nycklar. Att följa sådana konventioner kan göra vissa programmeringsuppgifter enklare.
Ingen av dessa frågor är deal-breakers. Och det finns också fördelar med att använda naturliga nycklar:
-
Om du slår upp rader efter användarnamn oftare än du söker efter id, kan det vara bättre att välja användarnamnet som primärnyckel, och dra nytta av den indexorganiserade lagringen av InnoDB. Gör din primära uppslagskolumn att vara den primära nyckeln, om möjligt, eftersom primärnyckelsökningar är mer effektiva i InnoDB (du bör använda InnoDB i MySQL).
-
Som du märkte, om du redan har en unik begränsning för användarnamn, verkar det vara ett slöseri med lagring att behålla en extra id-kolumn som du inte behöver.
-
Att använda en naturlig nyckel innebär att främmande nycklar innehåller ett värde som kan läsas av människor, istället för ett godtyckligt heltals-id. Detta tillåter frågor att använda det främmande nyckelvärdet utan att behöva gå tillbaka till den överordnade tabellen för det "riktiga" värdet.
Poängen är att det inte finns någon regel som täcker 100 % av fallen. Jag rekommenderar ofta att du håller dina alternativ öppna och använder naturliga nycklar, sammansatta nycklar och surrogatnycklar även i en enda databas.
Jag tar upp några frågor om surrogatnycklar i kapitlet "ID krävs" i min bok SQL-antimönster:undvika fallgroparna med databasprogrammering .