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

Question

Я должен добавить некоторую безопасность для C#/. Net Winforms/Desktop Application. Я использую Oracle DB Back-End.

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

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

Поскольку ни один из двух человек никогда не мог иметь одинаковое имя учетной записи Windows ... даже когда я не контролирую эти имен управление (NetOps делает, поэтому я хочу использовать учетные записи Windows, поэтому мне не нужно управлять им;)). Для таблицы ролей я должен снова никогда не иметь значения DUPE - я контролирую вход, будет только 3 (тактическое приложение исчезнет в течение года). USERROLE-это таблица JOIN, которая будет представлять отношения между пользователями и ролями, поэтому ни один сурручный ключ не является оправданным.

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

Answer 1

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

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

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

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

Answer 2

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

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