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

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

Таблицы просты: пользователь (идентификатор, имя), роль (идентификатор, роль), пользовательская роль (идентификатор пользователя, идентификатор роли).

Я использую имя учетной записи Windows для заполнения таблицы пользователей. Таблица ролей пока будет просто «Admin», «SuperUser», «BasicUser» ...

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

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

Ответы [ 2 ]

2 голосов
/ 16 декабря 2010

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

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

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

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

1 голос
/ 15 декабря 2010

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

  • Согласованность : Если каждая таблица имеет один искусственный ключ, вы всегда знаете имя ключа, когда знаете имя таблицы.
  • Простота использования : меньше ввода - одна клавиша означает, что предложения ON и WHERE короче и поэтому менее подвержены ошибкам.
  • Совместимость : Некоторые ORM хорошо работают только с таблицами с одним столбцом первичного ключа.
...