Какой из них был бы лучшим образцом для проектирования базы данных для хранения прав доступа?Дизайн базы данных прав доступа
Ваш первый вариант не такой гибкий, как он мог быть, и ваш второй вариант не такой управляемый, каким он мог быть.
Стандартный шаблон для контроля доступа называется Ролевая безопасность. Так как и число пользователей и, количество разных типов разрешений, которые вам нужны, управление вашими ссылками на права доступа становится все труднее.
Например, если у вас есть пять администраторов и пятьдесят пользователей, как вы сохраняете разрешения каждой группы в синхронизации? Когда один из ваших пользователей будет назначен администратору, сколько изменений вы должны сделать? Ответ состоит в том, чтобы создать два пересечения: пользователей к ролям и ролей к разрешениям.
I думаю, в большинстве случаев решение №2 намного лучше. Я бы отбросил флаг «hasallowed» в этом решении и вставлял только данные права пользователя в таблицу прав.
Вариант 1 подходит для простых систем. Один запрос дает вам одну строку со всей необходимой информацией. Это очень эффективно. Эффективность «хорошая». И это может даже квалифицироваться как «лучше» для ваших нужд.
Вариант 2 отличен, если права действия, скорее всего, будут расширены с течением времени непредсказуемым образом и будут использоваться по существу изолированными модулями, которые хотят подтвердить, что пользователь имеет доступ только к своей уникальной подсистеме. Это сложнее в том, что «соединение» должно выполняться при одновременном извлечения как актера, так и информации о доступе. Но мне нравится присоединиться, поэтому я не буду говорить неэффективно слишком громко, и DBS построены, чтобы быть хорошими в них. Используйте индексы с умом, и они в порядке.
Использование таблиц ссылок является более сложным с точки зрения кодирования. Вы разделили свои данные и поэтому должны писать более сложный код, который имеет дело с каждым разным его фрагментом. Однако я лично считаю, что это «хорошая» сложность в том, что каждая уникальная часть данных имеет свою собственную уникальную часть (ы) зависимого кода. Позволяет модульность и унарное инкапсулирование функциональности.