Ответ 1
Даже если ваше имя пользователя уникально, есть несколько преимуществ наличия дополнительного столбца id вместо того, чтобы использовать varchar в качестве основного ключа.
-
Некоторые люди предпочитают использовать целочисленный столбец в качестве первичного ключа, чтобы служить в качестве суррогатного ключа, который никогда не нуждается в изменении, даже если другие столбцы могут быть изменены. Хотя ничто не мешает естественному первичному ключу быть изменчивым, вам придется использовать каскадные ограничения внешнего ключа, чтобы гарантировать, что внешние ключи в связанных таблицах обновляются в синхронизации с любым таким изменением.
-
Первичный ключ, являющийся 32-разрядным целым, а не varchar, может сэкономить место. Хорошей причиной может быть выбор между столбцом внешнего ключа int или varchar в каждой другой таблице, которая ссылается на вашу таблицу пользователей.
-
Вставка в индекс первичного ключа немного более эффективна, если вы добавляете новые строки в конец индекса, по сравнению с их вклиниванием в середину индекса. Индексами в таблицах MySQL обычно являются структуры данных B + Tree, и вы можете изучить их, чтобы понять, как они выполняются.
-
Некоторые структуры приложений предпочитают, чтобы каждая таблица в вашей базе данных имела столбец первичного ключа, называемый
id
, вместо использования естественных ключей или составных ключей. После таких соглашений можно упростить некоторые задачи программирования.
Ни одна из этих проблем не является разрывом сделок. И есть также преимущества использования естественных ключей:
-
Если вы будете искать строки по имени пользователя чаще, чем поиск по идентификатору, лучше выбрать имя пользователя в качестве первичного ключа и воспользоваться хранилищем InnoDB, организованным индексом. Сделайте свой основной столбец поиска первичным ключом, если это возможно, потому что поиск первичных ключей более эффективен в InnoDB (вы должны использовать InnoDB в MySQL).
-
Как вы заметили, если у вас уже есть уникальное ограничение на имя пользователя, кажется, пустой тратой памяти для хранения лишнего столбца id, который вам не нужен.
-
Использование естественного ключа означает, что внешние ключи содержат удобочитаемое значение, а не произвольный целочисленный идентификатор. Это позволяет запросам использовать значение внешнего ключа без необходимости присоединяться к родительской таблице для "реального" значения.
Дело в том, что нет правила, которое охватывает 100% случаев. Я часто рекомендую вам открывать свои возможности и использовать естественные ключи, составные ключи и суррогатные ключи даже в одной базе данных.
Я расскажу о некоторых проблемах суррогатных ключей в главе "ID Обязательный" в моей книге Антиспам SQL: устранение ошибок программирования баз данных.