Суррогатный ключ в таблицах «Пользователь» / «Роль» для настольного приложения? Какова цель?

Мне нужно добавить некоторую безопасность для приложения C#/.NET WinForms/Desktop. Я использую серверную часть Oracle DB.

Таблицы просты: Пользователь (ID,Имя), Роль(ID,Роль), UserRole(UserID,RoleID).

Я использую имя учетной записи Windows для заполнения таблицы пользователей. Таблица ролей на данный момент будет просто «Администратор», «Суперпользователь», «Обычный пользователь»…

Поскольку никакие два человека не могут иметь одно и то же имя учетной записи Windows ... даже если я не контролирую это управление именами (netops контролирует, поэтому я хочу использовать учетные записи Windows, поэтому мне не нужно управлять им ;)). Для таблицы ролей у меня снова никогда не должно быть дублирующего значения — я контролирую ввод, их будет только 3 (тактическое приложение исчезнет в течение года). UserRole — это таблица соединений для представления отношений пользователей и ролей «многие ко многим», поэтому суррогатный ключ не оправдан.

Простой вопрос. Зачем использовать идентификатор (int) в таблице "Пользователи и роли"? Какой-то смысл или преимущество здесь? Это что-то из разряда "я всегда так делал"? Или я просто давно этого не делал и забыл причину?


authentication authorization oracle surrogate-key
person dferraro    schedule 15.12.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

Одно предостережение. Специально для очень узких таблиц с несколькими путями доступа вы можете использовать индексно-организованную таблицу. Oracle разрешает индексировать таблицу только по первичному ключу, но разрешает внешние ключи по уникальному набору столбцов (если это налагается ограничением уникальности, а не просто уникальным индексом).

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

person Gary Myers    schedule 15.12.2010
comment
Если у вас есть суррогатный ключ, но нет другой комбинации столбцов, которая однозначно идентифицирует строку, подумайте еще раз, правильно ли вы определили свое определение сущности. - Ах ах. Помимо очевидного обновления значений, если вам когда-либо приходилось это делать, в 1000 раз проще — это было предложение, которое я искал. Боже, интересно, когда я стану старше, сколько из этих базовых вещей я забуду и какое соотношение новых вещей, которые я узнаю, соответствует ли это (директор Келли Банди) - person dferraro; 20.12.2010

arrow_upward
1
arrow_downward

Суррогатный ключ не требуется для таблиц пересечения, но вот несколько причин для этого:

  • Согласованность: если каждая таблица имеет один искусственный ключ, вы всегда знаете имя ключа, когда знаете имя таблицы.
  • Простота использования: меньше печатать — одна клавиша означает, что предложения ON и WHERE короче и, следовательно, менее подвержены ошибкам.
  • Взаимодействие. Некоторые ORM хорошо работают только с таблицами с одним столбец первичного ключа.
person D'Arcy Rittich    schedule 15.12.2010