看起来你有两张桌子:
CREATE TABLE Permissions (
permissionID int identity(1,1),
userID int,
menuID int);
CREATE TABLE PermissionChildren (
permissionChildID int identity(1,1),
permissionID int,
permissionOption int);
假设用户 123 有权查看菜单 234 中的所有城市,那么您将拥有如下内容:
INSERT INTO Permissions (userID, menuID) VALUES (123, 234);
INSERT INTO PermissionChildren (permissionID, permissionOption) VALUES (@@identity, -1);
假设用户 456 仅有权查看菜单 234 中的几个城市,那么您将拥有如下内容:
INSERT INTO Permissions (userID, menuID) VALUES (456, 234);
DECLARE @permissionID int = @@identity;
INSERT INTO PermissionChildren (permissionID, permissionOption) VALUES (@permissionID, 11);
INSERT INTO PermissionChildren (permissionID, permissionOption) VALUES (@permissionID, 22);
INSERT INTO PermissionChildren (permissionID, permissionOption) VALUES (@permissionID, 44);
我将在这里做一些假设:
- 有多个菜单。
- 有些菜单有子权限,有些则没有。
- 大多数菜单没有子权限。
- 一个菜单可以有多个子权限。
- 添加新菜单子项时,具有 all 权限的用户应具有访问权限,但其他用户不应具有访问权限。
- 您想要支持的查询类似于:给定一个用户,找到该用户有权访问的所有菜单以及所有相关的子权限。
我喜欢你的架构。你肯定需要Permissions
。这将支持您没有子菜单的菜单。
PermissionChildren
还需要支持多个子权限。我认为你不需要permissionChildID
。SQL Server 无论如何都会为您创建一个唯一的 ID。但是,如果您的惯例是在每张桌子上都有 ID,那也不会很糟糕。
我不喜欢的-1
部分permissionOption
。我认为没有相应的行PermissionChildren
应该意味着用户拥有所有孩子的所有权限。原因是当菜单没有任何子权限时,它不应该在PermissionChildren
. 此配置意味着有权访问该菜单的每个用户也有权访问所有子项(全部为 0)。当第一个子菜单被添加到菜单时,所有对该菜单具有权限的现有用户都将拥有该菜单的权限。
不过,总的来说,我喜欢你到目前为止所做的事情。