Лучший способ представления пользовательских ролей в базе данных

Является ли представление прав пользователя лучше в таблице пользователей или лучше в его собственной таблице разрешений?

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

Разрешения в таблице разрешений, соединенные с таблицей User со отношениями "многие-ко-многим"
Выполнение этого способа чисто отделяет разрешения от пользовательской таблицы, но для доступа к разрешениям пользователя требуется объединение двух таблиц. Доступ к базе данных может быть медленнее, но дизайн базы данных кажется более чистым.

Возможно, сохранение разрешений в отдельной таблице лучше, когда есть много разрешений. Каковы другие соображения при принятии этого решения и какой дизайн лучше в различных ситуациях?

Ответы

Ответ 1

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

Например, если у вас есть пять администраторов и пятьдесят пользователей, как вы сохраняете разрешения каждой группы в синхронизации? Когда один из ваших пользователей будет назначен администратору, сколько изменений вы должны сделать? Ответ заключается в создании двух перекрестков: роли для пользователей и ролей для разрешений.

Это решение описывается (включая диаграмму отношений сущности) в моем ответе на этот вопрос.

enter image description here

Ответ 2

Ваш первый подход возможен, когда количество разных ролей/разрешений относительно невелико. Например, если у вас есть только два типа пользователей: обычный и административный, отдельная таблица выглядит как перебор. Одиночный столбец is_admin достаточен и прост.

Однако этот подход не масштабируется, как только количество ролей превышает несколько. Он имеет несколько недостатков:

  • таблица пользователей становится очень "широкой" с большим количеством пустых столбцов (теряя пространство)

  • Добавление новой роли в систему требует изменения таблицы пользователей. Это громоздко и может потребовать много времени для большой базы данных пользователей.

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