Это схема базы данных, которую мы имеем.
t_RoleCombination - Это все возможные комбинации разрешений, которые может иметь роль.
t_Permissions_Hierarchy - Это обеспечивает права доступа. Например, если у роли есть разрешения на Create
некоторого ресурса, она должна иметь права на Edit
этого ресурса, а если она имеет разрешение на Edit
, она должна иметь разрешение на View
. У нас также есть разрешение Share
, которое, если назначено, должно также обеспечивать разрешение View
. Таким образом, если роль имеет разрешение Create
, она также должна иметь разрешение View
, но может не иметь разрешения Share
. Из-за этой сложности мы не можем навязать иерархию в виде дерева, имея столбец ParentPermissionId в t_Permissions и поэтому имеем эту таблицу t_PermissionHierarchy.
t_RoleCombination_Permissions - это таблица сопоставления, которая фактически определяет все комбинации разрешений.
Пример данных t_Permissions
таблицы
Пример данных t_PermissionsHierarchy
Таблица
Когда клиент обновляет Роль, на сервере я получаю набор разрешений, который мне нужно сопоставить с одним из набора в таблице t_RoleCombinations_Permissions
, и получаю RoleCombinationId
для его обновления в таблице t_Roles
, Разделенное запятыми значение для набора разрешений передается в SP через параметр, и я могу сделать его набором записей с помощью функции с табличным значением, аналогичной указанной в , указанной здесь , если это необходимо.
UPDATE: -
-Я думал о создании столбца Varchar (Max) в t_RoleCombination для хранения разделенных запятыми отсортированных PermissionIds. Но это не хорошо в реляционной базе данных.
- Заявление, которое я мог бы подумать, приведено ниже. Но это не сработает, поскольку оператор IN
проверяет логические OR
, а не AND
.
SELECT RoleCombinationId from t_RoleCombinations_Permissions
WHERE PermissionId in (1,2,3,4,5) -- my comma saperated permissions
GROUP BY RoleCombinationId
HAVING Count(*) = 5 -- number of permissions specified.