My<cod/>.net
Лучше ли структурировать таблицу SQL, чтобы иметь совпадение, или не возвращать результат
У меня есть интересный вопрос дизайна. Я разрабатываю сторону безопасности нашего проекта, чтобы позволить нам иметь разные версии программы для разных затрат, а также позволить пользователям типа менеджера предоставлять или запрещать доступ к частям программы другим пользователям. Его собираются на веб-основе и размещены на наших серверах.
Я использую простой параметр Разрешить или запретить для каждого 'Resource' или экрана.
У нас будет большое количество ресурсов, и пользователь сможет настроить множество различных групп, чтобы пользователи могли контролировать доступ. Каждый пользователь может принадлежать только к одной группе.
У меня есть два подхода к этому в виду, и мне было любопытно, что было бы лучше для сервера SQL с точки зрения производительности.
Опция A наличие записи в таблице доступа означает, что доступ разрешен. Для этого не потребуется столбец в базе данных для хранения информации. Если результаты не возвращаются, то доступ запрещен.
Я думаю, что это будет означать меньшую таблицу, но будут ли запросы искать всю таблицу, чтобы определить, что нет соответствия?
Опция B битовый столбец включен в базу данных, которая управляет Allow/Deny. это будет означать, что всегда есть результат, который нужно найти, и делает для большей таблицы.
Мысли?
Если это будет только Allow/Deny,, то простая таблица ссылок между пользователями и ресурсами будет работать нормально. Если в таблице связей есть запись, связанная с пользовательским ресурсом, разрешите доступ.
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) запрос будет ослепительно быстрым даже с миллионами записей.
Я бы проголосовал за вариант B. Если вы идете с вариантом A и предположением, что если пользователь существует, они могут войти, то вы в конечном итоге столкнетесь с проблемой, что вы захотите запретить доступ к пользователю, не удаляя запись пользователя.
Будет много случаев, когда вы захотите заблокировать пользователя, но не захотите полностью уничтожить его учетную запись. Один из таких случаев (не обязательно связанный с вашим прецедентом) - это когда вы не платите, и они отключают ваш аккаунт, пока вы не начнете платить снова. Они не хотят удалять запись, потому что они все еще хотят включить ее, когда вы снова заплатите, вместо того, чтобы воссоздать учетную запись с нуля и потерять всю историю пользователей.
Подход A, но я бы также включил явный отказ в дополнение к вам неявный deney. Я бы сделал несколько вариантов использования, чтобы убедиться, что ваша конечная логика работает, но вот несколько примеров.
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 будет разрешен.
B. Это позволяет гораздо лучше проверить, являются ли данные полными (например, когда вы добавляете допустимую/отрицаемую функцию).
Кроме того, размер таблицы должен учитываться только для таблиц, которые, как вы знаете, будут содержать много записей (например, 100 000+). Вы даже не торопитесь вводить размер таблицы в этот вопрос, который уже стоит больше, чем дополнительное пространство на жестком диске, которое потребуется.