Очевидно, что у нас уже есть уникальная информация о каждом пользователе, и это имя пользователя. Тогда почему нам нужен еще один уникальный предмет для каждого пользователя? Почему у нас также должен быть идентификатор для каждого пользователя? Что произойдет, если мы опустим столбец id?
Почему у нас должен быть столбец идентификатора в таблице пользователей?
Ответ 1
Даже если ваше имя пользователя уникально, есть несколько преимуществ наличия дополнительного столбца id вместо того, чтобы использовать varchar в качестве основного ключа.
-
Некоторые люди предпочитают использовать целочисленный столбец в качестве первичного ключа, чтобы служить в качестве суррогатного ключа, который никогда не нуждается в изменении, даже если другие столбцы могут быть изменены. Хотя ничто не мешает естественному первичному ключу быть изменчивым, вам придется использовать каскадные ограничения внешнего ключа, чтобы гарантировать, что внешние ключи в связанных таблицах обновляются в синхронизации с любым таким изменением.
-
Первичный ключ, являющийся 32-разрядным целым, а не varchar, может сэкономить место. Хорошей причиной может быть выбор между столбцом внешнего ключа int или varchar в каждой другой таблице, которая ссылается на вашу таблицу пользователей.
-
Вставка в индекс первичного ключа немного более эффективна, если вы добавляете новые строки в конец индекса, по сравнению с их вклиниванием в середину индекса. Индексами в таблицах MySQL обычно являются структуры данных B + Tree, и вы можете изучить их, чтобы понять, как они выполняются.
-
Некоторые структуры приложений предпочитают, чтобы каждая таблица в вашей базе данных имела столбец первичного ключа, называемый
id
, вместо использования естественных ключей или составных ключей. После таких соглашений можно упростить некоторые задачи программирования.
Ни одна из этих проблем не является разрывом сделок. И есть также преимущества использования естественных ключей:
-
Если вы будете искать строки по имени пользователя чаще, чем поиск по идентификатору, лучше выбрать имя пользователя в качестве первичного ключа и воспользоваться хранилищем InnoDB, организованным индексом. Сделайте свой основной столбец поиска первичным ключом, если это возможно, потому что поиск первичных ключей более эффективен в InnoDB (вы должны использовать InnoDB в MySQL).
-
Как вы заметили, если у вас уже есть уникальное ограничение на имя пользователя, кажется, пустой тратой памяти для хранения лишнего столбца id, который вам не нужен.
-
Использование естественного ключа означает, что внешние ключи содержат удобочитаемое значение, а не произвольный целочисленный идентификатор. Это позволяет запросам использовать значение внешнего ключа без необходимости присоединяться к родительской таблице для "реального" значения.
Дело в том, что нет правила, которое охватывает 100% случаев. Я часто рекомендую вам открывать свои возможности и использовать естественные ключи, составные ключи и суррогатные ключи даже в одной базе данных.
Я расскажу о некоторых проблемах суррогатных ключей в главе "ID Обязательный" в моей книге Антиспам SQL: устранение ошибок программирования баз данных.
Ответ 2
Этот идентификатор известен как Суррогатный ключ. Связанная с вами страница содержит как преимущества, так и недостатки.
На практике я нашел их полезными, потому что даже данные суперкласса могут меняться со временем (т.е. адрес электронной почты пользователя может измениться, и поэтому любые соответствующие отношения должны измениться), но суррогатный ключ никогда не должен изменяться для данных, которые он идентифицирует, потому что его значение не имеет смысла для отношения.
Это также хорошо с точки зрения JOIN
, поскольку оно может быть целым числом с меньшей длиной ключа, чем varchar.
Я могу сказать, что на практике я предпочитаю их использовать. Я был укушен слишком много раз, имея несколько первичных ключей с несколькими столбцами или суперклассу данных, используемую в таблицах, чтобы впоследствии стать неповторимым из-за изменения требований во время разработки, и это не та ситуация, с которой вы хотите иметь дело.
Ответ 3
im mysql у нас есть.
1:Index fields 2:Unique fields and 3:PK fields.
index means pointable
unique means in a table must be one in all rows.
PK = index + unique
в таблице у вас может быть много уникальных полей, таких как
имя пользователя или код паспорта или адрес электронной почты.
но вам нужно поле, подобное ID. это как уникальное, так и index (= PK), которое является первым, всегда одно и никогда не изменяется, а второе является уникальным, а третье - простым (потому что часто число).
Ответ 4
Одна из причин наличия числового идентификатора заключается в том, что создание индекса на нем более компактное, чем в текстовом поле, уменьшая размер индекса и время обработки, необходимые для поиска конкретного пользователя. Кроме того, это меньше байтов для сохранения при перекрестном привязке к пользователю (реляционной базе данных) в другой таблице.
Ответ 5
По-моему, каждая таблица должна иметь уникальный, автоматически увеличиваемый идентификатор.
Вот некоторые практические причины. Если у вас есть повторяющиеся строки, вы можете легко определить, какую строку удалить. Если вы хотите знать порядок, в который были вставлены строки, у вас есть эта информация в id. Что касается пользователей, то больше, чем на "Джона Смита" в мире. Идентификатор предоставляет ключ для иностранных ссылок.
Наконец, почти все, что может описать пользователя, - имя, адрес, номер телефона, адрес электронной почты - могут со временем меняться.