Är sträng eller int att föredra för främmande nycklar?

Det beror på

Det finns många befintliga diskussioner på avvägningarna mellan naturliga och surrogatnycklar - du måste bestämma dig för vad som fungerar för dig och vad "standarden" är inom din organisation.

I OP:s fall finns det både en surrogatnyckel (int userId ) och en naturlig nyckel (char eller varchar username ). Båda kolumnerna kan användas som en primärnyckel för tabellen, och hur som helst kommer du fortfarande att kunna framtvinga den andra nyckelns unika karaktär.

Här är några överväganden när du väljer det ena eller det andra sättet:

Följet för att använda surrogatnycklar (t.ex. UserId INT AUTO_INCREMENT)

Om du använder ett surrogat, (t.ex. UserId INT AUTO_INCREMENT ) som primärnyckel, sedan alla tabeller som refererar till tabellen MyUsers ska sedan använda UserId som främmande nyckel.

Du kan dock fortfarande tvinga fram unika username kolumn genom användning av ett ytterligare unikt index , t.ex.:

CREATE TABLE `MyUsers` (
  `userId` int NOT NULL AUTO_INCREMENT,
  `username` varchar(100) NOT NULL,
  ... other columns
  PRIMARY KEY(`userId`),
  UNIQUE KEY UQ_UserName (`username`)

Enligt @Dagon, med en smal primärnyckel (som en int ) har prestanda- och lagringsfördelar jämfört med att använda ett bredare (och variabel längd) värde som varchar . Denna fördel påverkar även ytterligare tabeller som refererar till MyUsers , som främmande nyckel till userid kommer att vara smalare (färre byte att hämta).

En annan fördel med surrogatheltalsnyckeln är att användarnamnet enkelt kan ändras utan att det påverkar tabeller som hänvisar till MyUsers .Om username användes som en naturlig nyckel, och andra tabeller är kopplade till MyUsers via username , det gör det mycket obekvämt att ändra ett användarnamn (eftersom Foreign Key-relationen annars skulle kränkas). Om uppdatering av användarnamn krävdes i tabeller med username som främmande nyckel, en teknik som ON UPDATE CASCADE behövs för att behålla dataintegriteten.

Följet för att använda naturliga nycklar (dvs användarnamn)

En nackdel med att använda Surrogate Keys är att andra tabeller som refererar till MyUsers via en surrogatnyckel måste JOIN vara ed tillbaka till MyUsers tabellen om Username kolumn krävs. En av de potentiella fördelarna med naturliga nycklar är att om en fråga bara kräver Username kolumn från en tabell som hänvisar till MyUsers , att den inte behöver gå tillbaka till MyUsers för att hämta användarnamnet, vilket kommer att spara lite I/O-overhead.