Похоже, у вас есть как суррогатный ключ (int userId), так и натуральный ключ (char или varchar username). Любой столбец можно использовать в качестве первичного ключа для таблицы, и в любом случае вы все равно сможете обеспечить уникальность другого ключа.
Существует множество дискуссий о компромиссах между естественными и суррогатными ключами - вам нужно будет решить, что работает для вас и каков «стандарт» в вашей организации.
Вот некоторые соображения при выборе того или иного пути:
Случай использования суррогатных ключей (например, UserId INT AUTO_INCREMENT)
Если вы используете суррогат (например, UserId INT AUTO_INCREMENT) в качестве первичного ключа, то все таблицы, ссылающиеся на таблицу MyUsers, должны затем использовать UserId в качестве внешнего ключа.
Тем не менее, вы все равно можете применить уникальность столбца username, используя дополнительный уникальный индекс , например ::
CREATE TABLE `MyUsers` (
`userId` int NOT NULL AUTO_INCREMENT,
`username` varchar(100) NOT NULL,
... other columns
PRIMARY KEY(`userId`),
UNIQUE KEY UQ_UserName (`username`)
Согласно @Dagon, использование узкого первичного ключа (например, int) имеет преимущества в производительности и хранении по сравнению с использованием более широкого (и переменной длины) значения, такого как varchar. Это преимущество также влияет на другие таблицы, которые ссылаются на MyUsers, так как внешний ключ к userid будет сужаться.
Еще одним преимуществом суррогатного целочисленного ключа является то, что имя пользователя можно легко изменить, не затрагивая таблицы, ссылающиеся на MyUsers.
Если username использовался в качестве естественного ключа, то таблицы были связаны с MyUsers через username, что делает более неудобным изменение имени пользователя (поскольку в противном случае отношение внешнего ключа было бы нарушено). Если требуется обновить имена пользователей для таблиц, использующих username в качестве внешнего ключа, для сохранения целостности данных необходимо использовать метод, такой как ON UPDATE CASCADE .
Кейс для использования Natural Keys (т.е. имя пользователя)
С другой стороны, для использования суррогатных ключей для других таблиц, которые ссылаются на MyUsers через суррогатный ключ, всегда требуется join назад к таблице MyUsers для получения имени пользователя. Одним из потенциальных преимуществ естественных ключей является то, что если для запроса требуется только столбец Username из таблицы, ссылающейся на MyUsers, ему не нужно возвращаться к MyUsers для получения имени пользователя, что сэкономит некоторые накладные расходы.
Дальнейшие ссылки на естественные и суррогатные дебаты и компромиссы здесь и здесь