Лучше ли структурировать таблицу SQL, чтобы иметь совпадение, или не возвращать результат

Question

У меня интересный вопрос о дизайне. Я разрабатываю сторону безопасности нашего проекта, чтобы позволить нам иметь разные версии программы для разных затрат, а также чтобы пользователи типа менеджера могли предоставлять или запрещать доступ к частям программы другим пользователям. Он будет доступен через Интернет и размещен на наших серверах.

Я использую простой параметр «Разрешить» или «Запретить» для каждого «ресурса» или экрана.

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

Я имею в виду два подхода к этому, и мне было любопытно, что будет лучше для сервера SQL с точки зрения производительности.

Вариант A Наличие записи в таблице доступа означает, что доступ разрешен. Это не будет нуждаться в столбце в базе данных для хранения информации. Если результаты не возвращаются, доступ запрещен.

Я думаю, это будет означать меньшую таблицу, но будут ли запросы выполнять поиск по всей таблице, чтобы определить, что совпадений нет?

Вариант B Битовый столбец включен в базу данных, которая управляет разрешить / запретить. Это будет означать, что результат всегда будет найден, и приведет к увеличению таблицы.

Мысли

Answer 1

Если это будет только Разрешить / Запретить, тогда простая таблица связей между пользователями и ресурсами будет работать нормально. Если в таблице ссылок есть запись, привязанная к ресурсу пользователя, разрешите доступ.

UserResources
-------------
UserId FK->Users
ResourceId FK->Resources

и sql будет что-то вроде

if exists (select 1 from UserResources 
where UserId = @uid and ResourceId=@rid)
set @allow=1;

При включенном кластерном индексе (UserId и ResourceId) запрос будет ослепительно быстрым даже с миллионами записей.

Answer 2

Я бы проголосовал за Вариант B. Если вы выберете вариант А и исходите из предположения, что если пользователь существует, он может войти, то в конечном итоге вы столкнетесь с проблемой, из-за которой вы захотите запретить доступ пользователю , не удаляя запись пользователя.

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

Answer 3

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

User1 is in group1 and group2.  
User2 is in group1  
User3 is in group2 

---

Folder1 allows group1 and deny group2.  
User1 is denied.  
User2 is allowed.  
User3 is denied. 

Я полагаю, что ваш подход users1 будет разрешен.

Answer 4

B. Это позволяет гораздо лучше проверять, являются ли данные полными (например, при добавлении допустимой / запрещенной функции).

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