Создать идентификатор пользователя, даже если имена пользователей уникальны?

Question

Мое веб-приложение будет иметь различные типы пользователей: пользователь root, системные администраторы, клиенты, подрядчики и т. Д. Я хотел бы иметь таблицу "Пользователь", в которой будут столбцы "Имя пользователя", "Пароль" и " Роль "с ролью, являющейся одной из вышеупомянутых ролей. У меня, например, также будет таблица "Клиент" для хранения специфичных для клиента атрибутов.

Вот мой вопрос. Поскольку все имена пользователей будут уникальными, я мог бы использовать имя пользователя в качестве первичного ключа для таблицы User. Однако имеет ли смысл создавать столбец "Идентификатор пользователя" и использовать его вместо столбца "Имя пользователя" в качестве PK? Есть много других таблиц, которые будут использовать этот пользовательский PK в качестве внешнего ключа, и я думаю, что с точки зрения производительности будет быстрее сравнивать идентификаторы пользователей, а не текстовые строки имени пользователя.

Благодарю за ваш ответ.

Answer 1

Я бы создал идентификатор пользователя, потому что, хотя имена пользователей могут быть уникальными, они обычно не являются неизменяемыми, и я бы предпочел не менять тысячи или миллионы записей, потому что HLGEM хотел стать HLGEM_1. Дальнейшие объединения по целым числам быстрее.

Answer 2

Это старые естественные против суррогатных ключевых дебатов.

Короче говоря, нет ничего сложного, и вам нужно балансировать между конкурирующими интересами:

1. Если вы ожидаете, что вам нужно обновить ключ, используйте суррогат (который не нуждается в обновлении), чтобы избежать ON UPDATE CASCADE.
2. Если вам нужно найти ключ, но не другие столбцы, используйте естественный ключ, чтобы вообще избежать соединения. Но если вам нужно искать больше, чем просто ключ, используйте суррогат, чтобы сделать FK и сопровождающие их индексы более тонкими и эффективными.
3. Вы ожидаете сканирования диапазона на естественном ключе? Если да, группируйте это. Однако вторичные индексы могут быть дорогими в кластеризованных таблицах, что играет против суррогатного ключа.
4. Ваш стол очень большой? Экономьте место, имея только один индекс (для натурального ключа) вместо двух (для натурального и суррогатного).
5. Составные естественные ключи (которые находятся на дочерних конечных точках идентификации отношений) могут быть необходимы для правильного моделирования ромбовидных зависимостей.
6. Суррогаты могут быть более дружественными к инструментам ORM.

В случае имен пользователей...

1. Возможно, вы захотите разрешить обновление.
2. Вряд ли вам понадобится искать только имя пользователя.
3. Сканирование диапазона имен пользователей не имеет смысла (в отличие от экви-поиска).
4. Вы не храните все население Земли, не так ли?
5. Мы говорим об "автономном" естественном ключе здесь, а не о естественном ключе, который является результатом идентифицирующих отношений.
6. Неизвестный?

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

Answer 3

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

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