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

5

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

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

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

Хотя само собой разумеется, что бы вы ни выбрали, не храните пароли в открытом тексте. LittleBobbyTables

Ваш Ответ

3   ответа
3

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

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

3

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

5

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

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

  1. If you anticipate you'll need to update the key, use surrogate (which doesn't need updating) to avoid ON UPDATE CASCADE.
  2. If you need to lookup the key, but not the other columns, use natural key to avoid the JOIN altogether. But if you need to lookup more than just the key, use surrogate to make FKs and accompanying indexes slimmer and more efficient.
  3. Do you anticipate range scans on the natural key? If yes, cluster it. However, secondary indexes can be expensive in clustered tables, which plays against a surrogate key.
  4. Is your table very large? Save space by having only one index (on natural key) instead of two (on natural and surrogate).
  5. Composite natural keys (that are at the child endpoints of identifying relationships) may be necessary for correctly modeling diamond-shaped dependencies.
  6. Surrogates may be more friendly to ORM tools.

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

  1. You'll probably want to allow the update.
  2. It's unlikely you'll need to lookup only the username.
  3. Range scans on usernames make no sense (unlike equi-searches).
  4. You aren't storing the whole population of the Earth, are you?
  5. We are talking about "stand alone" natural key here, not a natural key that is the result of an identifying relationship.
  6. Unknown?

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

Спасибо, Бранко. Вы затронули некоторые интересные моменты, которые я не учел. Я решил использовать суррогатный ключ, как вы и HLGEM предложили. Jim

Похожие вопросы