数据库权限表设计

最近项目的项目很奇怪,一个大项目(系统)里包含了很多小的子系统,而这些子系统中都有权限控制的部分,这件事情挺让我头痛的,记得一年前在沈阳,我曾经有一段时间也因因这个问题而疲于奔命,为什么说疲于奔命呢?由于当时项目进度不允许,导致最终系统权限模块草草了事,每个模块都是由读权限字符串来控制用户ACL,当用户无法访问时,提示权限不够。这么做对用户是很不负责任的,既然让用户看到了操作的方式和界面,为什么又告诉用户没有权限呢?我开始怀疑我们是否应该在底层就封杀用户的访问权限。

现在项目开展起来了,虽然目前我已经有了对权限控制的一套方案,并且实施成了我的可重用框架代码,虽然目前的权限也是基于众星捧月的AOP思想,但我至今对权限设计仍有两个疑惑:

疑惑一:很多同行提出方案,想要在底层就截取用户权限,控制用户对方法或者类的访问。这样做的好处在于可以将系统功能与业务逻辑松散耦合,并且实现简单,结构清晰,三两个advisor、filter,或者acegi就能搞定,但在web程序中体现出了他的劣势,当我们将用户的访问拒绝在业务逻辑之外的时候,我们此时是否应该抛出异常提示用户?一旦提示用户没有相应的权限,我认为对于用户来说,这就不是一个perfectpractice。由此得出,我们根本就不应该让用户做此次操作,而控制用户操作的源头就是界面,也就是说,在界面上我们就应该对用户的权限元素(如添加按钮、功能菜单等)进行控制。此时,一对矛盾出现了,要控制界面上形形色色的元素只有两种办法,一,将权限与你的界面结合起来设计,这将违背AOP的思想,也使得系统控制模块的重用性大大下降,二,我们借鉴primeton的想法,将权限控制的理念抽取出来,单独做成一套权限系统,解决你所有的需要权限控制的系统需求,这样也有令人头痛的问题,你的所有想用它来控制权限的系统,必须界面上统一风格。或许这样的方式对商业web系统是合适的,毕竟需要你大刀阔斧个性化的地方不多,但我们却很难保证在未来几年内商业web系统的风格不改变。再者,开发这么一个系统也不是一蹴而就的事,在这个问题上一直让我困惑不已。

疑惑二:大多应用的权限判定是基于权限字符串的,但存储在数据库中的权限字符串能够判定的权限并不多,在我们这次项目中,我引用了基于二进制的8421权限判定法则,我深深的感觉到权限字符串的弱势,这使我想起了中国古老一套数学理论-“盈不足术”,超递增序列的魅力在我眼前滑过,

首先我来解释一下盈余不足理论:有十只盒子,第一个盒子里放一个盘子,第二个盒子里放两只,第三个盒子里放四只,第四个盒子里放八只……第九个盒子里放256只,第十个盒子放512只,即第N只箱子里放2^(N-1)只盘子,一共1023只。那么命题如下:在1023这个数字之内,任何一个数目都可以由这十只盒子里的几只组合相加而成。那么1、2、4、8、16、32、64、128、256、512这个序列为什么有这么个魔力?这个数列的特点:1、每项是后一项的二倍,2、每项都比前面所有项的和大,而且大1。这个1就是关键,就因为这个1,它才可以按 1递增,拼出总和之内任意一个整数。这个序列叫做超递增序列,它是解决背包问题的基础。3、拼出总和之内任意一个整数可以由这个序列中的一些数构成,且构成方法唯一,据说是密码学中的NP定理。譬如说这个数列总合中20这个数,只能由16+4一种方法构成,由此延伸出来,如果综合中这个数据代表一个权值,我们可以解出它的所有构成参数(操作),如20这个数据,我们可以挨个和序列中每一项按位与,得出来如果不等于0,就说明他是由这个数构成的。

保存权值到int还是varchar对于我们来说是个问题,当然,保存字符串的好处是运算压力小。我们可能听过一个故事,就是把这个超递增序列延伸到第64 项,就是那个术士和皇帝在国际象棋棋盘上要米粒的传说。64项的和是一个天文数字!但计算机本身就是一个只认识二进制的机器!很多程序员整天只关心架构,甚至不知道或者不关心位操作是什么玩意,当然我们有朋友担心数据库的int不够长,那么既然可以保存一个只有0、1组成的varchar字符串,为什么不能保存一个十六进制的字符串,有人规定varchar只能保存01吗?十六进制串的长度正好是二进制的四分之一。

由此我们可以无限制的扩展权值操作。

在最近的项目里,我对权限的控制分成两个部分,第一就是用户体验上,我设置了一个权限标签,从数据库中抽取权限信息,然后做到标签里,也凑或算成是界面 AOP了,第二就是底层的拦截,用了spring 的AOP,为的是防止权限冲突,双管齐下。暂时解决权限所需,另外在算法上我用了16进制的权限判别代码,虽然配置较麻烦,写完代码还要写文档说明,不过也解决了权限繁杂又多的问题,暂时就这样了,嘿嘿,以后有空再研究。

用户认证管理设计方案

1 设计思路

为了设计一套具有较强可扩展性的用户认证管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下。

1.1 用户

用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。

用户通常具有以下属性:

ü        编号,在系统中唯一。

ü        名称,在系统中唯一。

ü        用户口令。

ü        注释,描述用户或角色的信息。

1.2 角色

角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限,通常具有以下属性:

ü        编号,在系统中唯一。

ü        名称,在系统中唯一。

ü        注释,描述角色信息

1.3 权限

权限指用户根据角色获得对程序某些功能的操作,例如对文件的读、写、修改和删除功能,通常具有以下属性:

ü        编号,在系统中唯一。

ü        名称,在系统中唯一。

ü        注释,描述权限信息

1.4 用户与角色的关系

一个用户(User)可以隶属于多个角色(Role),一个角色组也可拥有多个用户,用户角色就是用来描述他们之间隶属关系的对象。用户(User)通过角色(Role)关联所拥有对某种资源的权限,例如

l        用户(User):

UserID     UserName      UserPwd

1                  张三                xxxxxx

2                  李四                xxxxxx

……

l        角色(Role):

RoleID          RoleName          RoleNote

01                 系统管理员       监控系统维护管理员

02                 监控人员          在线监控人员

03                 调度人员          调度工作人员

04                 一般工作人员   工作人员

……

l        用户角色(User_Role):

UserRoleID         UserID          RoleID           UserRoleNote

1                     1                  01                 用户“张三”被分配到角色“系统管理员”

2                      2                  02                 用户“李四”被分配到角色“监控人员”

3                      2                  03                 用户“李四”被分配到角色“调度人员”

……

从该关系表可以看出,用户所拥有的特定资源可以通过用户角色来关联。

1.5 权限与角色的关系

一个角色(Role)可以拥有多个权限(Permission),同样一个权限可分配给多个角色。例如:

l        角色(Role):

RoleID          RoleName          RoleNote

01                 系统管理员       监控系统维护管理员

02                 监控人员          在线监控人员

03                 调度人员          调度工作人员

04                 一般工作人员   工作人员

……

l        权限(Permission):

PermissionID     PermissionName       PermissionNote

0001                       增加监控                允许增加监控对象

0002                       修改监控                允许修改监控对象

0003                       删除监控                允许删除监控对象

0004                       察看监控信息       允许察看监控对象

……

l        角色权限(Role_Permission):

RolePermissionID  RoleID PermissionID RolePermissionNote

1                           01           0001        角色“系统管理员”具有权限“增加监控”

2                           01           0002        角色“系统管理员”具有权限“修改监控”

3                           01           0003        角色“系统管理员”具有权限“删除监控”

4                           01           0004        角色“系统管理员”具有权限“察看监控”

5                           02           0001        角色“监控人员”具有权限“增加监控”

6                           02           0004        角色“监控人员”具有权限“察看监控”

……

由以上例子中的角色权限关系可以看出,角色权限可以建立角色和权限之间的对应关系。

1.6 建立用户权限

用户权限系统的核心由以下三部分构成:创造权限、分配权限和使用权限

第一步由Creator创造权限(Permission),Creator在设计和实现系统时会划分。利用存储过程CreatePermissionInfo(@PermissionName,@PermissionNote)创建权限信息,指定系统模块具有哪些权限。

第二步由系统管理员(Administrator)创建用户和角色,并且指定用户角色(User-Role)和角色权限(Role-Permission)的关联关系。

1)        具有创建用户、修改用户和删除用户的功能: Administrator

l        存储过程CreateUserInfo(@UserName,@UserPwd)创建用户信息;

l        存储过程ModifyUserInfo(@UserName,@UserPwd)修改用户信息;

l        存储过程DeleteUserInfo(@UserID)删除用户信息;

2)        具有创建角色和删除角色的功能: Administrator

l        存储过程CreateRoleInfo(@RoleName,@RoleNote)创建角色信息;

l        存储过程DeleteRoleInfo(@RoleID)删除角色信息;

3)Administrator具有建立用户和角色、角色和权限的关联关系功能:

l        存储过程GrantUserRole(@UserID,@RoleID,@UserRoleNote)建立用户和角色的关联关系;

l        存储过程DeleteUserRole(@UserRoleID)删除用户和角色的关联关系;

l        存储过程GrantRolePermission(@RoleID,@PermissionID,@RolePermissionNote)建立角色和权限的关联关系;

l        存储过程DeleteRolePermission(@RolePermissionID)删除角色和权限的关联关系;

第三步用户(User)使用Administrator分配给的权限去使用各个系统模块。利用存储过程GetUserRole(@UserID, @UserRoleID output),GetRolePermission(@RoleID,@Role-

-PermissinIDoutput)获得用户对模块的使用权限。

1.7 用户认证实现

当用户通过验证后,由系统自动生成一个128位的TicketID保存到用户数据库表中,建立存储过程Login(@UserID,@UserPwd, @TicketID output)进行用户认证,认证通过得到一个TicketID,否则TicketID为null。其流程图如下:

图1 Login流程图

得到TicketID后,客户端在调用服务端方法时传递TicketID,通过存储过程JudgeTicketPermission(@TicketID,@PermissionID)判断TicketID对应的用户所具有的权限,并根据其权限进行方法调用。

当用户退出系统时,建立存储过程Logout(@UserID)来退出系统。当用户异常退出系统时,根据最后的登陆时间(LastSignTime)确定用户的TickeID,建立存储过程ExceptionLogout(@UserID,@LastSignTime)处理用户的异常退出。

图2 Logout流程图

WebService可以采用SoapHeader中写入TicketID来使得TicketID从客户端传递给服务端。.NetRemoting可以采用CallContext类来实现TicketID从客户端传递给服务端。

2 数据库设计

2.1 数据库表

图3 数据库关系图

2.2 数据库表说明

2.2.1 用户表(Static_User)

Static_User


Static_User字段名


详细解释


类型


备注


UserID


路线编号


varchar(20)


PK


UserName


用户名称


varchar(20)


UserPwd


用户密码


varchar(20)


LastSignTime


最后登陆时间


datatime


SignState


用户登陆状态标记


int


TickeID


验证票记录编号


varchar(128)

2.2.2 角色表(Static_Role)

Static_Role


Static_User字段名


详细解释


类型


备注


RoleID


角色编号


varchar(20)


PK


RoleName


角色名称


varchar(20)


RoleNote


角色信息描述


varchar(20)

2.2.3 用户-角色表(Static_User_Role)

Static_User_Role


Static_User字段名


详细解释


类型


备注


UserRoleID


用户角色编号


varchar(20)


PK


UserID


用户编号


varchar(20)


FK


RoleID


角色编号


varchar(20)


FK


UserRoleNote


用户角色信息描述


varchar(20)

2.2.4 权限表(Static_Permission)

Static_Permission


Static_User字段名


详细解释


类型


备注


PermissionID


编号


varchar(20)


PK


PermissionName


权限名称


varchar(20)


PermissionNote


全息信息描述


varchar(20)

2.2.5 角色-权限表(Static_Role_Permission)

Static_Role_Permission


Static_User字段名


详细解释


类型


备注


RolePermissionID


角色权限编号


varchar(20)


PK


RoleID


角色编号


varchar(20)


FK


PermissionID


权限编号


varchar(20)


FK


RolePermissionNote


角色权限信息描述


varchar(20)

用“位”来存储、修改用户权限的方法

以前我用记录方式,如A用户有3个模块权限,则A有三条记录

看到别人的程序里有这种方法,感觉不错,给大家看看有没有优点可取。

用户权限用一个int字段表示,可以放32位,

如果有第1,3,4模块的权限则,值为1 4 8=13

___________________

_userId_____userQx___

A??????????????|???? 13

_________|___________

增加权限具体实现

如增加第四个模块的权限,4的二进制值8

update qxUser setuserQx = userQx|8 where userId=‘A‘

删除第四个模块的权限

update qxUser setuserQx = userQx&~8 where userId=‘A‘

如果删除第四个模块,则不加条件就可以了

update qxUser setuserQx = userQx&~8

以上在SqlServer2000企业版通过。

欢迎大家讨论,有更好的方法大家共享呀~~~

Java 里

34&2 !=0就行了。

通过二,三两步的理解,相信这篇文章就不会生涩了!~ 

首先上文权限设计拙见(1)中只是想记录下自己权限设计上的一点看法,以及将自己日常最常用的权限解决方案记录下来以供日后回顾,没想到有朋友关注此类的设计,那就只能先把代码拿出来献丑了,抛砖引玉,大家共同探讨学习 
      接着上文来说,上文所讨论的权限设计是一条思路,但既然是web应用,少不了数据库的支持,本文我们来讨论一下数据库的设计。(以下想法及思路仅仅代表本人拙见)
      说到权限的数据库设计,必先理清权限中几种实体及其关系,此部分想必有过设计权限经验的同仁都知道怎么设计了,网上摆渡一下也是一裤衩子一裤衩子的,我们就在最平凡直观的数据库关系的基础上来建立权限。下面是我的几个表(所有的表都带有一个pk_id,作为表的自动生成的唯一主键):
用户表(T_UserInfo):

1 /**//*==============================================================*/
 2/**//* Table: T_UserInfo                                            */
 3/**//*==============================================================*/
 4create table T_UserInfo 
 5( 
 6    pk_id                NUMBER                         not null,
 7    name                 VARCHAR2(20),
 8    sex                  BOOLEAN,
 9    age                  int,
10    emp_num              NUMBER,
11    polity               int,
12    unit                 VARCHAR2(50),
13    department           VARCHAR2(20),
14    specialty            int,
15    position             VARCHAR2(10),
16    offtel               VARCHAR2(20),
17    famtel               VARCHAR2(20),
18    post_state           VARCHAR2(10),
19    remark               VARCHAR2(100),
20    constraint PK_T_USERINFO primary key (pk_id)
21);

实战经验:用户表就不多说了,都是一些常用字段,年龄、电话、职位等,建议大家建立一个通用一些,字段多一些的一个用户表,便于以后扩展,以后如果有特殊需求,不用扩这个基本表,可以通过主外键关系来新建一个表,用于扩充字段

角色表(T_RoleInfo):

1 /**//*==============================================================*/
 2/**//* Table: T_RoleInfo                                            */
 3/**//*==============================================================*/
 4create table T_RoleInfo 
 5(
 6    pk_id                number                         not null,
 7    role_name            VARCHAR2(20),
 8    role_desc            VARCHAR2(100),
 9    parent_role_id       NUMBER,
10    constraint PK_T_ROLEINFO primary key (pk_id)
11);

角色表中需要说明的就一个parent_role_id父角色id,此字段用来扩展角色的继承关系。

资源表(T_ResourceInfo):

1 /**//*==============================================================*/
 2/**//* Table: T_ResourceInfo                                        */
 3/**//*==============================================================*/
 4create table T_ResourceInfo 
 5(
 6    pk_id                NUMBER                         not null,
 7    module_name          VARCHAR2(20),
 8    module_code          VARCHAR2(10),
 9    module_desc          VARCHAR2(100),
10    privilege_name       VARCHAR2(10),
11    privilege_code       CHAR,
12    privilege_desc       VARCHAR2(100),
13    constraint PK_T_RESOURCEINFO primary key (pk_id)
14);
15

这个表需要说明的就比较多了,首先该表用来记录资源与资源权限,我这边所谓的资源就是实体,就是数据库表,角色需要对应到资源,有些角色对该资源有权限,有些角色则对该资源无权限,角色可对此资源操作的权限也不同。说白了,就是不同的角色对不同的数据库表的操作权限不同。因此我们这里的资源就是数据库表。

module_name:资源名;module_code:资源代码(存放数据库表名)
privilege_name:权限名;privilege_code:权限代码(代表权限的code,也就是我们上文所说的权值

例如角色a对数据库表T_UserInfo有添加与删除的权限则该表应该按照如下配置:

module_name:人员信息;
module_code:T_UserInfo
privilege_name:添加与删除
privilege_code:6

这里我们假设的是2的0次方为添加权限,2的1次方为添加权限,2的2次方为删除权限,2的3次方为更新权限,则拥有添加与删除权限就应该为2的1次方+2 的2次方=6,其实2的几次方代表什么含义我们可以另外开个数据库表来配置(或者xml文件)此处我们忽略这些步骤。当然如果你的权限较多,譬如你还希望 a这个角色对人员信息表有上传得权限,我们可以将将上传权限定义为2的4次方,16,16的16进制数为10,记录在数据库里的形式应该为0x10如果a 角色拥有添加、删除、更新、上传权限,则a的权值应该为2的1次方+2的2次方+2的3次方+2的4次方=30,用16进制来表示就应该为0x1E,记录 16进制数据,你不用担心位数不够。
剩余的就是几张关系表了:

人员角色关系表(T_R_User_Role):

1 /**//*==============================================================*/
 2/**//* Table: T_R_user_role                                         */
 3/**//*==============================================================*/
 4create table T_R_user_role 
 5(
 6    pk_id                NUMBER                         not null,
 7    user_id              NUMBER,
 8    role_id              NUMBER,
 9    constraint PK_T_R_USER_ROLE primary key (pk_id)
10);
11

角色资源关系表(T_R_Role_Resource)

1 /**//*==============================================================*/
 2/**//* Table: T_R_role_resource                                     */
 3/**//*==============================================================*/
 4create table T_R_role_resource 
 5(
 6    pk_id                NUMBER                         not null,
 7    role_id              NUMBER,
 8    res_id               NUMBER,
 9    constraint PK_T_R_ROLE_RESOURCE primary key (pk_id)
10);
11

当然如果你不怕麻烦,可以添加进去组(group)、系统(system)、组织(organization),建立起一套属于你自己的完整的权限解决方案,作为系统无关的模块去套用到每个你所架构的应用中去,那是一件极爽的事情。

时间: 2024-10-29 19:09:37

数据库权限表设计的相关文章

数据库分表设计-任我行

本文只阐述一个完整的实例,直接可以复制过去用,不作过多的解释. 简单说一下分表与分区: 分区的原理:我在深圳市,但我也在中国,如果中国没有划分区域的话,搜索范围将是整个中国,查询起来很费力.现在既然中国已经划分区域当然可以直接来深圳市找我了,是不是快了很多. 分表的原理:我在中国,通过某种算法(比如查户口)知道了我在深圳,是不是也可以直接来深圳市找我,其他区域就不用去看了,本文的算法为dbo.GetTableName(),通过这个算法知道了数据存储在哪张表里面. --用于保存所有日志ID,与操作

权限表设计之代码解析

在权限表设计中已经说了权限表的结构,在这里我说下代码 user表 </pre><pre name="code" class="html">@Entity @Table(name="user") public class User implements Serializable{ private static final long serialVersionUID = 6177417450707400228L; @Id @G

权限表设计

设计表:Users 用户表 字段:userid,username,userpermissionRoles 角色表 字段:roleid,rolename,rolepermissionUserInRole 用户角色相应表 字段:userid,roleidPermissionList 权限列表 字段:permissionid,permissionDescription,permissionGroup 权限设计:许可.禁止和未设置三种状态,Allow,Deny,Not Set 目标:实现用户权限的定义.

数据库字典表设计

在稍大一些的项目中,我们总是需要管理各种各样的类型类型数据(如商品类型.游戏类型...).对于这些类型的管理类似,如果为每 一种类型都建立一张表去维护(而在项目中,正常出现50种类型),那工作量是可想而之大,并且我们不得不去了解每一个类型表的名字, 以去关联它. 因此,我们需要一种数据模型以完成对多种多样类型管理的需求. 字典表dictionary 字段名           类型               是否可空    中文名         描述 dict_name    varchar

数据库的表设计

创建数据库里最基本的应该就是建表,建索引.存储过程等一系列操作了.谈到表就不得不谈到实体. 一.数据实体 什么是实体,客观存在并且可以相互区别的事物称为实体.这里我们就简单的把它理解为一个表吧,描述实体的特性,我们就把他们称为了属性.也可以说当我们把一个数据库表当作一个实体,那么它里面的所有字段是不是就是一个属性了呢?结果是肯定的. 二.实体间的联系 我想说的是,很简单,数据库里表跟表间的关系莫过于三种:一对一:多对多:一对多. 一对一其实就是说我们建的主表跟相关联的表之间是一一对应的,比如说,

数据库分表设计

具体来说就是数据库有这样的表account0account1account2account3 每个表假如说是存1万个玩家sprintf(m_szSql,"UPDATE account%d SET rmcard=rmcard + %lld,coin=coin + %lld,safecoin=safecoin + %lld where uid=%d;",CCommonLogic::GetDataTableNum(uid),roomCard,coin,safecoin,uid); 这是分表的

mysql数据库关系表设计原则

https://blog.csdn.net/qq_36432666/article/details/78934073 https://kb.cnblogs.com/page/138526/ http://blog.sina.com.cn/s/blog_a29f7cb50101jr5d.html https://www.cnblogs.com/mjbrian/p/6841226.html https://blog.csdn.net/persistencequxi/article/details/7

ERP开发分享 1 数据库表设计

这是我的ERP设计经验分享系列,今天讲的是数据库的表设计(1),主要阐述: 1.单字段的主键:2.使用int32作为主键类型:3.使用版本字段处理乐观锁定:4.生效字段标明是否允许“被使用”:5.锁定字段处理悲观锁定:6.行唯一字段处理分布式应用:

数据库表设计后不允许保存更改

在修改 SQL Server 2012 数据库的表设计后,保存表设计时,出现如下错误提示: 不允许保存更改.您所做的更改要求删除并重新创建以下表.您对无法重新创建的标进行了更改或者启用了“阻止保存要求重新创建表的更改”选项. 解决方法 打开“工具”->“选项”,展开“设计器”->“表设计器和数据库设计器”, 去掉“阻止保存要求重新创建表的更改”前面的勾.