Используя имя пользователя столбец вместо идентификатора?

Question

Это настройка для базы данных для управления пользователями, которую я нашел где-то в Интернете (написано в псевдокоде). Хотя это выглядит совершенно нормально, я не понимаю, почему в таблице users есть столбец id, а также уникальный, не нулевой столбец username. Не могу ли я просто использовать имя пользователя в качестве id (первичный ключ)?

users
(
  id integer primary key,
  username varchar(100) not null unique key,
  pwd varchar(50) not null
);

user_roles
(
  user_id integer not null,
  role_id integer not null,
  unique key (user_id, role_id),
  index(user_id)
);

roles
(
  id integer primary key,
  role varchar(100) not null unique key
);

Answer 1

Я всегда прибегаю к рекомендациям Кимберли Л. Триппа о ключе кластеризации (который по умолчанию является первичным ключом в SQL Server).

Ее критерии таковы, что ключ кластеризации должен быть:

• Уникальный (связь между идентификатором и именем)
• Узкий (+1 для ID)
• Статический ( возможно +1 для идентификатора, в зависимости от того, разрешено ли изменение имени)
• Постоянно увеличивающееся ( возможно +1 для ID, в зависимости от того, как оно реализовано, использование столбца IDENTITY здесь было бы идеальным случаем)

Answer 2

Вы могли бы (используйте user_id в качестве первичного ключа ).

Единственное препятствие, которое я вижу, таково: если когда-либо необходимо изменить user_id ( Стефани Смит выходит замуж за какого-то парня по имени Джонсон и нуждается в ее user_id замене), тогда требуется меньше обслуживания базы данных.

Где я работаю, кто-то настраивает нашу базу данных наиспользуйте user_id в качестве первичного ключа лет назад.Изменение этого теперь было бы кошмаром!

Плюс, int быстрее для поиска и может быть сгенерирован автоматически.

Answer 3

Да, вы можете использовать имя пользователя. Проблема в том, что потенциально нестабильные первичные ключи - это боль, потому что вам нужно каскадировать изменения для всех FK.

Также использование целых чисел в соединениях, как правило, работает лучше

Вы должны отметить, что то, что делает ключевую волатильность, несколько субъективно

Также, как упоминает JNK, существует оптимизация, когда кластеризованные индексы (обычно также PK) являются инкрементными. См. Статью Кимберли Л. Триппа Дебаты о кластеризованных индексах продолжаются

Answer 4

На высоком уровне ваши разговоры Natural против суррогатных ключей здесь.Есть компромиссы, оба из которых, я думаю, были упомянуты, но если вы хотите дополнительного чтения, я бы сказал, что эта ссылка хорошо подводит итог

«Натуральные и суррогатные ключи»

Answer 5

Я думаю, вы можете использовать имя пользователя в качестве первичного ключа.Может быть, этот пример использует столбец id для лучшей производительности.Я полагаю, быстрее искать в столбце Int, чем в текстовом.Также в таблице user_role есть user_id иностранного ключа.В этом случае не имеет смысла использовать строку (100) как foreign_key.

Answer 6

Это сделало бы присоединение к нему неэффективным: int s намного меньше, чем varchar(100), поэтому индекс будет меньше и быстрее.Обычно первичный ключ будет кластеризованным индексом таблицы.

Answer 7

По сути, идентификатор - это автоинкрементное значение, которое хранится в базе данных и используется для ссылок в сценариях БД, хотя имя пользователя также является уникальным столбцом.Самым большим преимуществом является то, что вашему пользователю не нужно запоминать какой-либо цифровой номер, который был назначен системе для входа в учетную запись, вместо этого он может выбирать свои уникальные имена пользователей и легко взаимодействовать.