67,513
社区成员
发帖
与我相关
我的任务
分享权限控制权限是如何实现
用户有好几个，一种是超级用户，超级用户可以实际系统的全部功能，一般用户，只有某一些权限，如果是以超级用户登录，那他就可以给一般用户赋不同的角设。一个用户拥有多个权限，多个权限属于一个用户，一个用户担任多种角设，多个角设属于同一个用户。
这个系统数据库是如何设计的，请各位大哥，大姐们指导指导。。
这个系统数据库是如何设计的，请各位大哥，大姐们指导指导。。
...全文
请发表友善的回复…
发表回复
hnxxhc 2010-02-20
- 打赏
- 举报
建一个角色表、一个用户表、一个角色用户中间表、一个权限表、一个权限角色中间表
lp19890601 2010-02-05
- 打赏
- 举报
[Quote=引用 4 楼 warison2008 的回复:]
权限表，用户表，用户权限表，角色权限表，用户角色表，
超级管理员，用户，一般管理员，用用户类型来区分
用户登录，先确认其用户类型，超级用户不用关联权限，加载全部
其他的加载权限= 用户权限 交集 （用户角色 关联 角色权限）
[/Quote]
权限控制就是这样实现的！
权限表，用户表，用户权限表，角色权限表，用户角色表，
超级管理员，用户，一般管理员，用用户类型来区分
用户登录，先确认其用户类型，超级用户不用关联权限，加载全部
其他的加载权限= 用户权限 交集 （用户角色 关联 角色权限）
[/Quote]
权限控制就是这样实现的！
colin_pxx 2010-02-05
- 打赏
- 举报
设置角色 然后角色可以继承
临远 2010-02-05
- 打赏
- 举报
权限控制就是这样实现的
http://www.family168.com/oa/springsecurity/html/
http://www.family168.com/oa/springsecurity/html/
Y_2716 2010-02-05
- 打赏
- 举报
[Quote=引用楼主 greatmind829 的回复:]
用户有好几个，一种是超级用户，超级用户可以实际系统的全部功能，一般用户，只有某一些权限，如果是以超级用户登录，那他就可以给一般用户赋不同的角设。一个用户拥有多个权限，多个权限属于一个用户，一个用户担任多种角设，多个角设属于同一个用户。
这个系统数据库是如何设计的，请各位大哥，大姐们指导指导。。
[/Quote]
这样实现太麻烦了把，一个用户多个角色。。。。。。。。。。
有必要这样？
用户有好几个，一种是超级用户，超级用户可以实际系统的全部功能，一般用户，只有某一些权限，如果是以超级用户登录，那他就可以给一般用户赋不同的角设。一个用户拥有多个权限，多个权限属于一个用户，一个用户担任多种角设，多个角设属于同一个用户。
这个系统数据库是如何设计的，请各位大哥，大姐们指导指导。。
[/Quote]
这样实现太麻烦了把，一个用户多个角色。。。。。。。。。。
有必要这样？
cfd406635982 2010-02-05
- 打赏
- 举报
顶
道光2008 2010-02-05
- 打赏
- 举报
权限表，用户表，用户权限表，角色权限表，用户角色表，
超级管理员，用户，一般管理员，用用户类型来区分
用户登录，先确认其用户类型，超级用户不用关联权限，加载全部
其他的加载权限= 用户权限 交集 （用户角色 关联 角色权限）
超级管理员，用户，一般管理员，用用户类型来区分
用户登录，先确认其用户类型，超级用户不用关联权限，加载全部
其他的加载权限= 用户权限 交集 （用户角色 关联 角色权限）
Magiccrystal 2010-02-05
- 打赏
- 举报
建一个角色表、一个用户表、一个角色用户中间表、一个权限表、一个权限角色中间表
丰富的分地方的 2010-02-05
- 打赏
- 举报
看看spring security
mingxian 2010-02-05
- 打赏
- 举报
建一个角色表、一个用户表、一个角色用户中间表、一个权限表、一个权限角色中间表
登录时跟据用户表的数据从角色用户中间表查询登录用户拥有哪些角色，再通过权限角色中间查询获得有哪些权限。
登录时跟据用户表的数据从角色用户中间表查询登录用户拥有哪些角色，再通过权限角色中间查询获得有哪些权限。
mxd841025 2010-02-05
- 打赏
- 举报
你年他们的太浪费时间。我告你一个方法，这个方法也是我们系统中用的！既然分管理员，一般用户。。。也就是这些用户是有层次关系的。有了层次关系就好办了！建一张人员表，人员表中最重要的一个字段就是人员编码，(EMPCODE)，这个EMPCODE是有规则的，为了以后控制整个系统的权限，规则如下：100 200 300..这一类三位编码代表最高级，对应的下级100100 200100 300100代表下级 100100100 200100100 300100100 代表下下级，以此累推，这样的话你在权限控制上写SQL的话很好写的，这可是整个系统的精华，其它那些小玩意我就不说了，你理解了这个的话，你做的系统以后想怎么扩展就怎么扩展！
QQ359120087 2010-02-05
- 打赏
- 举报
定2
yueguangkai001 2010-02-05
- 打赏
- 举报
我怎么看了半天都没有一个模块表
就算给你权限了,没有模块来控制你所需要的操作也难做吧
建议查看尚学堂的OA视频
就算给你权限了,没有模块来控制你所需要的操作也难做吧
建议查看尚学堂的OA视频
lgf11088 2010-02-05
- 打赏
- 举报
设置权限 都是建表 然后在表里进行操作啊 方法楼上的都有
sebatinsky 2010-02-05
- 打赏
- 举报
[Quote=引用 11 楼 taozhaocailiu 的回复:]
这属于Rbac方面的知识，用户、权限、角色三者设计关系。我们项目一般是这样设计的：
rbac数据库设计:设计数据库表实现完整的RBAC方法
如何设计数据库表实现完整的RBAC(基于角色权限控制)
RBAC(基于角色的权限控制)是一个老话题了，但是这两天我试图设计一套表结构实现完整的RBAC时，发现存
在很多困难。我说的完整的RBAC，是指支持角色树形结构和角色分组。具体来说，应当包含如下权限控制需求
：父级角色可以访问甚至是修改其子级的数据，包含直接子级直到最终子级。
角色可以访问其所在组的数据。
父级角色可以访问其所有子级(从直接子级到最终子级)所在组的数据。
而具体到我的系统中，还应当有如下需求。兼容多种数据库产品。只能用简单的表，视图，存储过程和函数等
实现。
同时兼容单条数据处理和批量数据处理的需求。
且不论这些具体需求，RBAC的基本表应当如下四个：roleList表，记录所有的角色和角色组。
roleId: PK, 角色/组的ID，全局唯一，不区分角色和组。
roleName:角色/组的名称。
roleType: R - 角色，G - 组
rolePermission表，记录每一个角色/组对每一个对象的权限。
permissionID: PK, 无特定意义。
role: 角色/组的ID。
object: 对象的ID。
permission: 权限标识，如读，写，删等。
roleRelationship表，记录角色/组之间的关系。
relationId: PK, 无特定意义。
superiorRole: 父角色/组的ID。
role:子角色，子组，成员角色，成员组的ID。
relationship: 关系标识，可在如下设置集中选取一个。
PG标识：P - 父子关系，G - 组/成员关系。
PPGG标识：在PG集上，再加三种：PP - 间接父级关系，GG - 组内组关系，CG - parentRole是组
，childRole的子角色或间接子角色是其成员，或其子组(含间接子组）的成员
objectList表，记录所有的对象。
objectId: PK，对象ID，全局唯一。
objectName: 对象名称。
... ...
分析上述表结构，不难发现，问题的关键在于从rolePermission表中读取数据时，如何限定角色/组的范围.方
案一如果角色和组的总量不大，比如在100以内，采用PPGG标识关系，读取数据时是最快的。这个时候的
SQL只需要一个输入参数?roleId：SELECT object FROM rolePermission p left join roleRelationship r
_disibledevent= ?roleId. (尚未验证SQL的正确性)但是，这个方案是以极度冗余roleRelationship表的数据为
代价的，比如有100个角色，那么roleRelationship中将会有100 * 100 ＝10,000条记录。而在每次调整角色和
R角色组的时候，就要在roleRelationship中一次增加或删除100条记录。这个开销是比较大的。方案二只标识
PG，查询时接收的输入参数为一个完整的相关角色列表?roleList。SELECT object FROM rolePermission
WHERE role in (?roleList)在系统运行时，这个?roleList通常可以从role hierarchy cache中取到，比较方便。
这个方案的主要问题有二：1）如果?roleList过长，使用in判断性能会很差。2）在有些情况下，如报表查询和
系统外查询时，取得roleList不太方便。方案三只标识PG，但使用如下三个数据库函数来判断角色/组之间的关
系。boolean isChild(role, parentRole) - 如role为parentRole的子，返回true。 [Page]
boolean isDescendant(role, ancestorRole) - 如role为ancestorRole的子或间接子级，返回true。
boolean isMember(role, group) - 如role为group的成员或子组的成员，返回true。
boolean descendantIsMember(role, group) - 如role的子或间接子级为group的成员，返回true。
boolean isBelong(role, super) - 如role为super的子，间接子，成员或间接员，或者role的子(含间接子)是
super的成员或子组成员，返回true。
在查询时，也只需要接收一个?roleId：SELECT object FROM rolePemission WHERE isBelong(?roleId,
role)如何写出高性能的数据库函数是实现这个方法的关键。上述方法仅是理论分析，我倾向于方案二。终于想
到新的方案了。方案四，结合方案一和方案二，在roleRelationship中，对前两级(也可以是三级或四级)角色
，保存其所有的下级角色和组。这样，如果以前两级角色查询数据，就使用方案一，如果以第三级及以下的角
色查询数据，就使用方案二。仍以100个角色为例，每个角色要保存三个关系：一级主管角色，二级主管角色
，直接主管角色，最多有300条数据。每往角色组中加一个角色，也需要加入三条数据：角色本身，一级主管
角色，二级主管角色。但往角色组中加一个子组，需要加入的数据量就大一些：子组本身，子组所有角色，子
组所有角色的一级主管角色和二级主管角色。如在多个子组中发现同一角色，可重复保存，但应在表中附加说
明是由哪个子组导入的。这样在删除子组时就可以有选择性的删除。但重复子组的情况就比较麻烦，还有等考
虑。假充有组g01,g11,g12,g21。g01包含g11和g12，g11和g12分别包含g21。从g01中删除g11时，如何判
断g21的去留?看来还是应当在维护时判断应不应当删除。
[/Quote]
说多了无用吧，
最主要的是楼主需要怎么样的控制内容。
比如简单的几个页面，没有那么复杂，直接写if语句就OK了，如果是比较大一点的，就可以设计表。自己理清楚思路，用户表，菜单表。权限表，用户权限表，权限可操作的菜单表。
这属于Rbac方面的知识，用户、权限、角色三者设计关系。我们项目一般是这样设计的：
rbac数据库设计:设计数据库表实现完整的RBAC方法
如何设计数据库表实现完整的RBAC(基于角色权限控制)
RBAC(基于角色的权限控制)是一个老话题了，但是这两天我试图设计一套表结构实现完整的RBAC时，发现存
在很多困难。我说的完整的RBAC，是指支持角色树形结构和角色分组。具体来说，应当包含如下权限控制需求
：父级角色可以访问甚至是修改其子级的数据，包含直接子级直到最终子级。
角色可以访问其所在组的数据。
父级角色可以访问其所有子级(从直接子级到最终子级)所在组的数据。
而具体到我的系统中，还应当有如下需求。兼容多种数据库产品。只能用简单的表，视图，存储过程和函数等
实现。
同时兼容单条数据处理和批量数据处理的需求。
且不论这些具体需求，RBAC的基本表应当如下四个：roleList表，记录所有的角色和角色组。
roleId: PK, 角色/组的ID，全局唯一，不区分角色和组。
roleName:角色/组的名称。
roleType: R - 角色，G - 组
rolePermission表，记录每一个角色/组对每一个对象的权限。
permissionID: PK, 无特定意义。
role: 角色/组的ID。
object: 对象的ID。
permission: 权限标识，如读，写，删等。
roleRelationship表，记录角色/组之间的关系。
relationId: PK, 无特定意义。
superiorRole: 父角色/组的ID。
role:子角色，子组，成员角色，成员组的ID。
relationship: 关系标识，可在如下设置集中选取一个。
PG标识：P - 父子关系，G - 组/成员关系。
PPGG标识：在PG集上，再加三种：PP - 间接父级关系，GG - 组内组关系，CG - parentRole是组
，childRole的子角色或间接子角色是其成员，或其子组(含间接子组）的成员
objectList表，记录所有的对象。
objectId: PK，对象ID，全局唯一。
objectName: 对象名称。
... ...
分析上述表结构，不难发现，问题的关键在于从rolePermission表中读取数据时，如何限定角色/组的范围.方
案一如果角色和组的总量不大，比如在100以内，采用PPGG标识关系，读取数据时是最快的。这个时候的
SQL只需要一个输入参数?roleId：SELECT object FROM rolePermission p left join roleRelationship r
_disibledevent= ?roleId. (尚未验证SQL的正确性)但是，这个方案是以极度冗余roleRelationship表的数据为
代价的，比如有100个角色，那么roleRelationship中将会有100 * 100 ＝10,000条记录。而在每次调整角色和
R角色组的时候，就要在roleRelationship中一次增加或删除100条记录。这个开销是比较大的。方案二只标识
PG，查询时接收的输入参数为一个完整的相关角色列表?roleList。SELECT object FROM rolePermission
WHERE role in (?roleList)在系统运行时，这个?roleList通常可以从role hierarchy cache中取到，比较方便。
这个方案的主要问题有二：1）如果?roleList过长，使用in判断性能会很差。2）在有些情况下，如报表查询和
系统外查询时，取得roleList不太方便。方案三只标识PG，但使用如下三个数据库函数来判断角色/组之间的关
系。boolean isChild(role, parentRole) - 如role为parentRole的子，返回true。 [Page]
boolean isDescendant(role, ancestorRole) - 如role为ancestorRole的子或间接子级，返回true。
boolean isMember(role, group) - 如role为group的成员或子组的成员，返回true。
boolean descendantIsMember(role, group) - 如role的子或间接子级为group的成员，返回true。
boolean isBelong(role, super) - 如role为super的子，间接子，成员或间接员，或者role的子(含间接子)是
super的成员或子组成员，返回true。
在查询时，也只需要接收一个?roleId：SELECT object FROM rolePemission WHERE isBelong(?roleId,
role)如何写出高性能的数据库函数是实现这个方法的关键。上述方法仅是理论分析，我倾向于方案二。终于想
到新的方案了。方案四，结合方案一和方案二，在roleRelationship中，对前两级(也可以是三级或四级)角色
，保存其所有的下级角色和组。这样，如果以前两级角色查询数据，就使用方案一，如果以第三级及以下的角
色查询数据，就使用方案二。仍以100个角色为例，每个角色要保存三个关系：一级主管角色，二级主管角色
，直接主管角色，最多有300条数据。每往角色组中加一个角色，也需要加入三条数据：角色本身，一级主管
角色，二级主管角色。但往角色组中加一个子组，需要加入的数据量就大一些：子组本身，子组所有角色，子
组所有角色的一级主管角色和二级主管角色。如在多个子组中发现同一角色，可重复保存，但应在表中附加说
明是由哪个子组导入的。这样在删除子组时就可以有选择性的删除。但重复子组的情况就比较麻烦，还有等考
虑。假充有组g01,g11,g12,g21。g01包含g11和g12，g11和g12分别包含g21。从g01中删除g11时，如何判
断g21的去留?看来还是应当在维护时判断应不应当删除。
[/Quote]
说多了无用吧，
最主要的是楼主需要怎么样的控制内容。
比如简单的几个页面，没有那么复杂，直接写if语句就OK了，如果是比较大一点的，就可以设计表。自己理清楚思路，用户表，菜单表。权限表，用户权限表，权限可操作的菜单表。
zl3450341 2010-02-05
- 打赏
- 举报
用户表 角色表 权限表
用户角色关联表 角色权限关联表下个dtree 根据权限显示相应的菜单
lolitaline 2010-02-05
- 打赏
- 举报
[Quote=引用 3 楼 magiccrystal 的回复:]
建一个角色表、一个用户表、一个角色用户中间表、一个权限表、一个权限角色中间表
[/Quote]
DDD
建一个角色表、一个用户表、一个角色用户中间表、一个权限表、一个权限角色中间表
[/Quote]
DDD
重返春季 2010-02-05
- 打赏
- 举报
具体设计表，可以这样：
/* 因为有人说光看脚本,看不明白我想说的是什么.我就把我想表达的东西说一下.关于RBAC(基于角色的访问控制)我也是在网上的一些资料上看来的.
权限系统就是要解决Who对What进行How的操作.我根据我对RBAC的一些理解写的底下的数据库的脚本代码在SQL Server上运行后会自动创建出一个数据库.
在SQL Server2005里能够看表的关系图.
对照我的测试数据和代码注释应该很容易就看出来我想说的是什么.
*/
use [master]
go
-- 检查数据库 [RBAC]是否存在,如果存在则删除(只测试用,不然会丢数据.)
-- Search from the sysdatabase to see that if the [RBAC] database exist.
-- If exists then drop it else create it.
if exists(select * from sysdatabases where name = 'RBAC')
drop database [RBAC]
go
-- 创建数据库 [RBAC]
-- Create the database named by '[RBAC]'.
create database [RBAC]
go
-- 使用数据库 [RBAC]
-- Use the database of '[RBAC]'.
use [RBAC]
go
-- 创建 "用户" 数据表 [RBAC_User]
-- Create the datatable named by '[RBAC_User]' to save users.
create table [RBAC_User]
(
--用户编号
[User_ID] int primary key not null,
--用户名称
[User_Name] varchar(20) not null,
--用户密码
[User_PassWord] varchar(20) not null,
--用户状态
[User_Lock] bit not null
)
go
-- 添加测试数据
-- Add data for test
insert into [RBAC_User] values(1,'FightingYang','PassWord',0);
go
insert into [RBAC_User] values(2,'Supper3000','Teacher',0);
go
insert into [RBAC_User] values(3,'JianzhongLi','Teacher',1);
go
select * from [RBAC_User]
go
-- 创建 "组" 数据表 [RBAC_Group]
-- Create the datatable named by '[RBAC_Group]' to save groups.
create table [RBAC_Group]
(
--组编号
[Group_ID] int primary key not null,
--组名称
[Group_Name] varchar(20) not null
)
go
-- 添加测试数据
-- Add data for test
insert into [RBAC_Group] values(1,'编程爱好者');
go
insert into [RBAC_Group] values(2,'MSDN老师');
go
select * from [RBAC_Group]
go
-- 创建 "角色" 数据表 [RBAC_Role]
-- Create the datatable named by '[RBAC_Role]' to save roles.
create table [RBAC_Role]
(
--角色编号
[Role_ID] int primary key not null,
--角色名称
[Role_Name] varchar(20) not null
)
go
-- 添加测试数据
-- Add data for test
insert into [RBAC_Role] values(1,'admin');
go
insert into [RBAC_Role] values(2,'user');
go
select * from [RBAC_Role]
go
-- 创建 "资源" 数据表 [RBAC_Resource]
-- Create the datatable named by '[RBAC_Resource]' to save Resources.
create table [RBAC_Resource]
(
--资源编号
[Resource_ID] int primary key not null,
--资源名称
[Resource_Name] varchar(20) not null
)
go
-- 添加测试数据
-- Add data for test
insert into [RBAC_Resource] values(1,'音频');
go
insert into [RBAC_Resource] values(2,'视频');
go
select * from [RBAC_Resource]
go
-- 创建 "操作" 数据表 [RBAC_Operate]
-- Create the datatable named by '[RBAC_Operate]' to save Operates.
create table [RBAC_Operate]
(
--操作编号
[Operate_ID] int primary key not null,
--操作名称
[Operate_Name] varchar(10) not null
)
go
-- 添加测试数据
-- Add data for test
insert into [RBAC_Operate] values(1,'添加');
go
insert into [RBAC_Operate] values(2,'读取');
go
insert into [RBAC_Operate] values(3,'编写');
go
insert into [RBAC_Operate] values(4,'删除');
go
select * from [RBAC_Operate]
go
-- 创建 "权限" 数据表 [RBAC_Privilege]
-- Create the datatable named by [RBAC_Privilege] to save privileges.
create table [RBAC_Privilege]
(
--权限编号
[Privilege_ID] int primary key not null,
--资源编号
[Resource_ID] int foreign key references [RBAC_Resource]([Resource_ID]) not null,
--操作编号
[Operate_ID] int foreign key references [RBAC_Operate]([Operate_ID]) not null
)
go
-- 添加测试数据
-- Add data for test
-- 第一条权限是对"音频"的"添加"权限
insert into [RBAC_Privilege] values(1,1,1);
go
-- 第二条权限是对"音频"的"读取"权限
insert into [RBAC_Privilege] values(2,1,2);
go
-- 第三条权限是对"音频"的"编写"权限
insert into [RBAC_Privilege] values(3,1,3);
go
-- 第四条权限是对"音频"的"删除"权限
insert into [RBAC_Privilege] values(4,1,4);
go
-- 第五条权限是对"视频"的"读取"权限
insert into [RBAC_Privilege] values(5,2,1);
go
-- 第六条权限是对"视频"的"读取"权限
insert into [RBAC_Privilege] values(6,2,2);
go
-- 第七条权限是对"视频"的"编写"权限
insert into [RBAC_Privilege] values(7,2,3);
go
-- 第八条权限是对"视频"的"删除"权限
insert into [RBAC_Privilege] values(8,2,4);
go
select * from [RBAC_Operate]
go
-- 创建 "授权" 数据表 [RBAC_Impower]
-- Create the datatable named by [RBAC_Impower] to save Impower.
create table [RBAC_Impower]
(
--授权编号
[Impower_ID] int primary key not null,
--角色编号
[Role_ID] int foreign key references [RBAC_Role]([Role_ID]) not null,
--权限编号
[Privilege_ID] int foreign key references [RBAC_Privilege]([Privilege_ID]) not null
)
go
-- 添加测试数据
-- Add data for test
-- 第一条授权内容"admin"具有'对"音频"的"添加"权限'
insert into [RBAC_Impower] values(1,1);
go
-- 第二条授权内容"admin"具有'对"音频"的"读取"权限'
insert into [RBAC_Impower] values(2,2);
go
-- 第三条授权内容"admin"具有'对"音频"的"编写"权限'
insert into [RBAC_Impower] values(3,3);
go
-- 第四条授权内容"admin"具有'对"音频"的"删除"权限'
insert into [RBAC_Impower] values(4,4);
go
-- 第五条授权内容"admin"具有'对"视频"的"添加"权限'
insert into [RBAC_Impower] values(5,5);
go
-- 第六条授权内容"admin"具有'对"视频"的"读取"权限'
insert into [RBAC_Impower] values(6,6);
go
-- 第七条授权内容"admin"具有'对"视频"的"编写"权限'
insert into [RBAC_Impower] values(7,7);
go
-- 第八条授权内容"admin"具有'对"视频"的"删除"权限'
insert into [RBAC_Impower] values(8,8);
go
-- 第九条授权内容"user"具有'对"音频"的"读取"权限'
insert into [RBAC_Impower] values(9,2);
go
-- 第十条授权内容"user"具有'对"视频"的"读取"权限'
insert into [RBAC_Impower] values(10,5);
go
select * from [RBAC_Impower]
go
-- 添加测试数据
-- Add data for test
-- 组所具备的角色的数据第一条的内容是"MSDN老师"具有"admin"的角色
insert into [RBAC_GroupRole] values(1,2,1);
go
-- 组所具备的角色的数据第二条的内容是"编程爱好者"具有"user"的角色
insert into [RBAC_GroupRole] values(2,1,2);
go
select * from [RBAC_GroupRole]
go
-- 创建 "用户组" 数据表 [RBAC_UserGroupRole]
-- Create the datatable named by '[RBAC_UserGroupRole]' to save userGroupRoles.
create table [RBAC_UserGroupRole]
(
--用户组编号
[UserGroup_ID] int primary key not null,
--用户编号
[User_ID] int foreign key references [RBAC_User]([User_ID]) not null,
--组编号
[Group_ID] int foreign key references [RBAC_Group]([Group_ID]) not null,
--角色编号
[Role_ID] int foreign key references [RBAC_Role]([Role_ID]) not null
)
go
-- 添加测试数据
-- Add data for test
-- 第一条用户组数据是"FightingYang"属于"编程爱好者"组,在组中的角色是"admin"
insert into [RBAC_UserGroup] values(1,1,1,1);
go
-- 第二条用户组数据是"Supper3000"属于"MSDN老师"组,在组中的角色是"admin"
insert into [RBAC_UserGroup] values(2,2,2,1);
go
-- 第三条用户组数据是"JianzhongLi"属于"MSDN老师"组,在组中的角色是"user"
insert into [RBAC_UserGroup] values(3,3,2,2);
go
select * from [RBAC_UserGroupRole]
go
重返春季 2010-02-05
- 打赏
- 举报
这属于Rbac方面的知识，用户、权限、角色三者设计关系。我们项目一般是这样设计的：
rbac数据库设计:设计数据库表实现完整的RBAC方法
如何设计数据库表实现完整的RBAC(基于角色权限控制)
RBAC(基于角色的权限控制)是一个老话题了，但是这两天我试图设计一套表结构实现完整的RBAC时，发现存
在很多困难。我说的完整的RBAC，是指支持角色树形结构和角色分组。具体来说，应当包含如下权限控制需求
：父级角色可以访问甚至是修改其子级的数据，包含直接子级直到最终子级。
角色可以访问其所在组的数据。
父级角色可以访问其所有子级(从直接子级到最终子级)所在组的数据。
而具体到我的系统中，还应当有如下需求。兼容多种数据库产品。只能用简单的表，视图，存储过程和函数等
实现。
同时兼容单条数据处理和批量数据处理的需求。
且不论这些具体需求，RBAC的基本表应当如下四个：roleList表，记录所有的角色和角色组。
roleId: PK, 角色/组的ID，全局唯一，不区分角色和组。
roleName:角色/组的名称。
roleType: R - 角色，G - 组
rolePermission表，记录每一个角色/组对每一个对象的权限。
permissionID: PK, 无特定意义。
role: 角色/组的ID。
object: 对象的ID。
permission: 权限标识，如读，写，删等。
roleRelationship表，记录角色/组之间的关系。
relationId: PK, 无特定意义。
superiorRole: 父角色/组的ID。
role:子角色，子组，成员角色，成员组的ID。
relationship: 关系标识，可在如下设置集中选取一个。
PG标识：P - 父子关系，G - 组/成员关系。
PPGG标识：在PG集上，再加三种：PP - 间接父级关系，GG - 组内组关系，CG - parentRole是组
，childRole的子角色或间接子角色是其成员，或其子组(含间接子组）的成员
objectList表，记录所有的对象。
objectId: PK，对象ID，全局唯一。
objectName: 对象名称。
... ...
分析上述表结构，不难发现，问题的关键在于从rolePermission表中读取数据时，如何限定角色/组的范围.方
案一如果角色和组的总量不大，比如在100以内，采用PPGG标识关系，读取数据时是最快的。这个时候的
SQL只需要一个输入参数?roleId：SELECT object FROM rolePermission p left join roleRelationship r
_disibledevent= ?roleId. (尚未验证SQL的正确性)但是，这个方案是以极度冗余roleRelationship表的数据为
代价的，比如有100个角色，那么roleRelationship中将会有100 * 100 ＝10,000条记录。而在每次调整角色和
R角色组的时候，就要在roleRelationship中一次增加或删除100条记录。这个开销是比较大的。方案二只标识
PG，查询时接收的输入参数为一个完整的相关角色列表?roleList。SELECT object FROM rolePermission
WHERE role in (?roleList)在系统运行时，这个?roleList通常可以从role hierarchy cache中取到，比较方便。
这个方案的主要问题有二：1）如果?roleList过长，使用in判断性能会很差。2）在有些情况下，如报表查询和
系统外查询时，取得roleList不太方便。方案三只标识PG，但使用如下三个数据库函数来判断角色/组之间的关
系。boolean isChild(role, parentRole) - 如role为parentRole的子，返回true。 [Page]
boolean isDescendant(role, ancestorRole) - 如role为ancestorRole的子或间接子级，返回true。
boolean isMember(role, group) - 如role为group的成员或子组的成员，返回true。
boolean descendantIsMember(role, group) - 如role的子或间接子级为group的成员，返回true。
boolean isBelong(role, super) - 如role为super的子，间接子，成员或间接员，或者role的子(含间接子)是
super的成员或子组成员，返回true。
在查询时，也只需要接收一个?roleId：SELECT object FROM rolePemission WHERE isBelong(?roleId,
role)如何写出高性能的数据库函数是实现这个方法的关键。上述方法仅是理论分析，我倾向于方案二。终于想
到新的方案了。方案四，结合方案一和方案二，在roleRelationship中，对前两级(也可以是三级或四级)角色
，保存其所有的下级角色和组。这样，如果以前两级角色查询数据，就使用方案一，如果以第三级及以下的角
色查询数据，就使用方案二。仍以100个角色为例，每个角色要保存三个关系：一级主管角色，二级主管角色
，直接主管角色，最多有300条数据。每往角色组中加一个角色，也需要加入三条数据：角色本身，一级主管
角色，二级主管角色。但往角色组中加一个子组，需要加入的数据量就大一些：子组本身，子组所有角色，子
组所有角色的一级主管角色和二级主管角色。如在多个子组中发现同一角色，可重复保存，但应在表中附加说
明是由哪个子组导入的。这样在删除子组时就可以有选择性的删除。但重复子组的情况就比较麻烦，还有等考
虑。假充有组g01,g11,g12,g21。g01包含g11和g12，g11和g12分别包含g21。从g01中删除g11时，如何判
断g21的去留?看来还是应当在维护时判断应不应当删除。
rbac数据库设计:设计数据库表实现完整的RBAC方法
如何设计数据库表实现完整的RBAC(基于角色权限控制)
RBAC(基于角色的权限控制)是一个老话题了，但是这两天我试图设计一套表结构实现完整的RBAC时，发现存
在很多困难。我说的完整的RBAC，是指支持角色树形结构和角色分组。具体来说，应当包含如下权限控制需求
：父级角色可以访问甚至是修改其子级的数据，包含直接子级直到最终子级。
角色可以访问其所在组的数据。
父级角色可以访问其所有子级(从直接子级到最终子级)所在组的数据。
而具体到我的系统中，还应当有如下需求。兼容多种数据库产品。只能用简单的表，视图，存储过程和函数等
实现。
同时兼容单条数据处理和批量数据处理的需求。
且不论这些具体需求，RBAC的基本表应当如下四个：roleList表，记录所有的角色和角色组。
roleId: PK, 角色/组的ID，全局唯一，不区分角色和组。
roleName:角色/组的名称。
roleType: R - 角色，G - 组
rolePermission表，记录每一个角色/组对每一个对象的权限。
permissionID: PK, 无特定意义。
role: 角色/组的ID。
object: 对象的ID。
permission: 权限标识，如读，写，删等。
roleRelationship表，记录角色/组之间的关系。
relationId: PK, 无特定意义。
superiorRole: 父角色/组的ID。
role:子角色，子组，成员角色，成员组的ID。
relationship: 关系标识，可在如下设置集中选取一个。
PG标识：P - 父子关系，G - 组/成员关系。
PPGG标识：在PG集上，再加三种：PP - 间接父级关系，GG - 组内组关系，CG - parentRole是组
，childRole的子角色或间接子角色是其成员，或其子组(含间接子组）的成员
objectList表，记录所有的对象。
objectId: PK，对象ID，全局唯一。
objectName: 对象名称。
... ...
分析上述表结构，不难发现，问题的关键在于从rolePermission表中读取数据时，如何限定角色/组的范围.方
案一如果角色和组的总量不大，比如在100以内，采用PPGG标识关系，读取数据时是最快的。这个时候的
SQL只需要一个输入参数?roleId：SELECT object FROM rolePermission p left join roleRelationship r
_disibledevent= ?roleId. (尚未验证SQL的正确性)但是，这个方案是以极度冗余roleRelationship表的数据为
代价的，比如有100个角色，那么roleRelationship中将会有100 * 100 ＝10,000条记录。而在每次调整角色和
R角色组的时候，就要在roleRelationship中一次增加或删除100条记录。这个开销是比较大的。方案二只标识
PG，查询时接收的输入参数为一个完整的相关角色列表?roleList。SELECT object FROM rolePermission
WHERE role in (?roleList)在系统运行时，这个?roleList通常可以从role hierarchy cache中取到，比较方便。
这个方案的主要问题有二：1）如果?roleList过长，使用in判断性能会很差。2）在有些情况下，如报表查询和
系统外查询时，取得roleList不太方便。方案三只标识PG，但使用如下三个数据库函数来判断角色/组之间的关
系。boolean isChild(role, parentRole) - 如role为parentRole的子，返回true。 [Page]
boolean isDescendant(role, ancestorRole) - 如role为ancestorRole的子或间接子级，返回true。
boolean isMember(role, group) - 如role为group的成员或子组的成员，返回true。
boolean descendantIsMember(role, group) - 如role的子或间接子级为group的成员，返回true。
boolean isBelong(role, super) - 如role为super的子，间接子，成员或间接员，或者role的子(含间接子)是
super的成员或子组成员，返回true。
在查询时，也只需要接收一个?roleId：SELECT object FROM rolePemission WHERE isBelong(?roleId,
role)如何写出高性能的数据库函数是实现这个方法的关键。上述方法仅是理论分析，我倾向于方案二。终于想
到新的方案了。方案四，结合方案一和方案二，在roleRelationship中，对前两级(也可以是三级或四级)角色
，保存其所有的下级角色和组。这样，如果以前两级角色查询数据，就使用方案一，如果以第三级及以下的角
色查询数据，就使用方案二。仍以100个角色为例，每个角色要保存三个关系：一级主管角色，二级主管角色
，直接主管角色，最多有300条数据。每往角色组中加一个角色，也需要加入三条数据：角色本身，一级主管
角色，二级主管角色。但往角色组中加一个子组，需要加入的数据量就大一些：子组本身，子组所有角色，子
组所有角色的一级主管角色和二级主管角色。如在多个子组中发现同一角色，可重复保存，但应在表中附加说
明是由哪个子组导入的。这样在删除子组时就可以有选择性的删除。但重复子组的情况就比较麻烦，还有等考
虑。假充有组g01,g11,g12,g21。g01包含g11和g12，g11和g12分别包含g21。从g01中删除g11时，如何判
断g21的去留?看来还是应当在维护时判断应不应当删除。
greatmind829 2010-02-05
- 打赏
- 举报
有哪位有相对应的 数据库设计图吗？
是不是根据用户登录的不同，进入系统的界面就不同了。
是不是根据用户登录的不同，进入系统的界面就不同了。
