Почему у нас должен быть столбец идентификатора в таблице пользователей?

Очевидно, что у нас уже есть уникальная информация о каждом пользователе, и это имя пользователя. Тогда почему нам нужен еще один уникальный предмет для каждого пользователя? Почему у нас также должен быть идентификатор для каждого пользователя? Что произойдет, если мы опустим столбец 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. Что касается пользователей, то больше, чем на "Джона Смита" в мире. Идентификатор предоставляет ключ для иностранных ссылок.

Наконец, почти все, что может описать пользователя, - имя, адрес, номер телефона, адрес электронной почты - могут со временем меняться.