Czy w przypadku kluczy obcych preferowane jest string czy int?

To zależy

Istnieje wiele istniejących dyskusji o kompromisach między kluczami naturalnymi i zastępczymi - musisz zdecydować, co działa dla Ciebie i jaki jest „standard” w Twojej organizacji.

W przypadku OP istnieje oba klucz zastępczy (int userId ) i klucz naturalny (char lub varchar username ). Każda kolumna może być użyta jako klucz podstawowy dla tabeli i tak czy inaczej, nadal będziesz mógł wymusić unikalność drugiego klucza.

Oto kilka uwag dotyczących wyboru jednego lub drugiego sposobu:

Przypadek użycia kluczy zastępczych (np. UserId INT AUTO_INCREMENT)

Jeśli używasz surogatu (np. UserId INT AUTO_INCREMENT ) jako klucz podstawowy, wszystkie tabele odwołują się do tabeli MyUsers powinien wtedy użyć UserId jako klucz obcy.

Nadal możesz jednak wymusić unikalność username kolumna poprzez użycie dodatkowego unikalnego indeksu , np.:

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

Zgodnie z @Dagon, używając wąskiego klucza głównego (takiego jak int ) ma zalety wydajności i pamięci w porównaniu z używaniem szerszej (i zmiennej długości) wartości, takiej jak varchar . Ta korzyść wpływa również na dalsze tabele, które odwołują się do MyUsers , jako klucz obcy do userid będzie węższy (mniej bajtów do pobrania).

Inną zaletą zastępczego klucza liczb całkowitych jest to, że nazwę użytkownika można łatwo zmienić bez wpływu na tabele odwołujące się do MyUsers .Jeśli username był używany jako klucz naturalny, a inne tabele są połączone z MyUsers przez username , zmiana nazwy użytkownika jest bardzo niewygodna (ponieważ w przeciwnym razie relacja klucza obcego zostałaby naruszona). Jeśli aktualizacja nazw użytkowników była wymagana w tabelach przy użyciu username jako klucz obcy, technika taka jak ON UPDATE CASCADE jest potrzebny do zachowania integralności danych.

Przypadek używania naturalnych kluczy (tj. nazwy użytkownika)

Jedną z wad używania kluczy zastępczych jest to, że inne tabele, które odwołują się do MyUsers za pomocą klucza zastępczego będzie musiał być JOIN ed z powrotem do MyUsers tabela, jeśli Username kolumna jest wymagana. Jedną z potencjalnych zalet kluczy naturalnych jest to, że jeśli zapytanie wymaga tylko Username kolumna z tabeli odwołującej się do MyUsers , że nie musi dołączyć z powrotem do MyUsers aby pobrać nazwę użytkownika, co oszczędzi trochę narzutu I/O.