下载文档原格式
权限设计权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。
一、数据库设计权限表及相关内容大体可以用六个表来描述，如下：1角色表：包括四个字段：角色ID，角色名，对该角色的描述,创建时间；2用户表：包括八个字段：用户ID，账户名称，姓名，联系电话，邮箱，密码，备注，创建时间等；3用户-角色表：包括三个字段：ID（编号，自增，方便维护，查询），用户ID，角色ID。
该表记录用户与角色之间的对应关系，一个用户可以隶属于多个角色，一个角色也可以拥有多个用户；4角色-权限表：包括三个字段：ID（编号，自增，方便维护，查询），角色ID，权限ID。
该表记录角色与权限之间的对应关系，一个权限可以隶属于多个角色，一个角色也可以拥有多个权限。
特别说明：若用户所属于两个角色，取出对应角色中的所有权限，则用户的权限为分别继承两个角色的权限的并集，过滤掉相同的权限取其中一个。
5权限表：权限表包括六个字段：权限ID，资源路径，权限名，用户展示，创建时间，描述。
权限类型包括三种：菜单、页面元素、资源路径。
a菜单：包括一级菜单、二级菜单（子菜单，可扩展菜单）菜单表：包括三个字段菜单ID，菜单名称，父菜单IDb页面元素：设置权限到页面的级别，所有的人都可以访问一个页面，一部分可以进行添加操作，一部分人可以进行删除操作，一部分可以进行审核工作等。
即设置同一个页面的不同操作权限。
c资源路径：如上传文件，文件的修改删除操作，资源路径的访问等。
用户展示为前端展示给用户的文字或图标（包括没有对应路径的图标），可选择展示或隐藏，表设计如下：1角色表（mp_role）字段名称字段类型备注角色ID role_id varchar(50) pk, not null角色名roleName varchar(255) not null描述description varchar(255)创建时间createTime varchar(255)2用户表（mp_user）字段名称字段类型备注用户ID user_id varchar(50) pk, not null账户名称userName varchar(255) not null姓名realName varchar(255) not null联系电话phone varchar(255)密码password varchar(25)邮箱email varchar(255)描述description varchar(255)创建时间createTime varchar(255)3用户-角色表（mp_user_role）字段名称字段类型备注ID id varchar(50) pk, not null 角色ID role_id varchar(50) fk, not null 用户ID user_id varchar(50) fk, not null 4角色-权限表(mp_role_permission)字段名称字段类型备注ID id varchar(50) pk, not null 角色ID role_id varchar(50) fk, not null 权限ID permission_id varchar(50) fk, not null 5权限表(mp_permission)字段名称字段类型备注权限ID id varchar(50) pk, not null 资源路径resourcePath varchar(255)权限名称permissionName varchar(255)用户展示display varchar(255)描述description varchar(255)创建时间createTime varchar(255)6二、应用程序接口(API)设计界面设计1新建角色，实现：用户可以继承所属角色的部分权限，如某用户所属于A和B两个角色，但分别继承它们的部分权限，设计为取两个角色权限的交集。
常用权限系统表格设计
{andy}
1.用户表
序号字段英文大小备注
1 自增编号UserID 主键
2 工号
3 用户名
4 密码
5 是否管理员ISAdmin Int 0否，1是
6 备注
2.角色表
序号字段英文大小备注
1 自增编号RoleID 主键
2 角色名称
3 备注
3.权限表
序号字段英文大小备注
1 自增编号RightID 主键
2 权限名称
3 备注
4.用户角色表
序号字段英文大小备注
1 自增编号UserRoleID 主键
2 UserID
3 RoleID
5.角色权限表
序号字段英文大小备注
1 自增编号RoleRightID 主键
2 RoleID
3 RightID
6.功能点（扩展表，可将权限控制到按钮）
序号字段英文大小备注
1 自增编号PointID 主键
2 权限操作点PointName 添/删/改/查...
称之为功能点
3 备注Remark
7.权限功能点（扩展表，可将权限控制到按钮）
序号字段英文大小备注
1 自增编号RightPointID 主键
2 权限ID RightID 一个模块的权限
如：用户管理，3 功能点ID PointID
下面有添加，删
除，修改等功能
点
4 备注Remark。
权限设计（功能权限与数据权限）权限设计的最终⽬标就是定义每个⽤户可以在系统中做哪些事情。
当我们谈到权限的时候，⼀般可以分为功能权限、数据权限和字段权限；功能权限：⽤户具有哪些权利，⽐如特定单据的增、删、改、查、审批、反审批等等；⼀般按照⼀个⼈在组织内的⼯作内容来划分；⽐如⼀个单据往往有录⼊⼈和审批⼈，录⼊⼈具有增、删、该、查的权限；⽽审批⼈具有审批、反审批和查询的权限。
有时，功能权限被细分为页⾯权限和操作权限。
数据权限：⽤户可以看到哪些范围的主数据，⽐如按照部门或业务条线来划分。
⽤户张三看到A团队的数据，⽤户李四只能看到B团队的数据。
字段权限：在特定的单据中，可以看到哪些字段；⽐如针对⼊库单，财务⼈员能看到采购成本，⽽库管员看不到等等。
字段权限和数据权限的区别在于，数据权限规定了哪些⾏的数据看不到，⽽字段权限规定了哪些列的数据看不到；这种权限设计现在见的⽐较少了，因为如果两个⽤户看到的列都不⼀样，通过设计不同的表单也能实现，此时字段权限就转换为功能权限了。
如上图所⽰，数据权限决定⽤户看到的是团队A还是团队B的数据，字段权限决定能否看到⾦额这⼀列的数据。
对功能权限和数据权限的抽象这个就是⾓⾊的引⼊，⽹上有很多这⽅⾯的⽂档介绍可以参考，我这⾥挑重点简单说⼀下；在⼀般的组织中，⽤户的权限是由岗位决定的，由于⽤户可能⾯临转岗、离职等⼯作；所以岗位和权限的关系⽐⽤户和岗位的关系要稳定的多。
所以为了简化⽤户权限的分配操作，降低操作风险；同时，也便于把权限管理移交给统⼀的⽤户管理部门，⼀般会引⼊⾓⾊的概念，作为功能权限和数据权限的抽象；注意：权限、⾓⾊和⽤户是多对多的关系；数据权限的进⼀步抽象考虑⼀种场景，⼀个集团有50个分⽀机构，每个分⽀机构下平均有3个部门，各个部门的组织架构是⼤体类似，在系统中都分为单据的录⼊者、复核者、审批者和查询者；这种情况下，如果按照⾓⾊来设置，需要设置50*3*4共600个⾓⾊；⽽且⼀旦⾯临的部门和团队的增加和撤销，也⾯临⾓⾊的⼤量设置和调整。
权限管理设计一•博客分类：•设计设计模式数据结构应用程序权限设计我们在开发系统的时候，经常会遇到系统需要权限控制，而权限的控制程度不同有不同的设计方案。
1.基于角色的权限设计这种方案是最常见也是比较简单的方案，不过通常有这种设计已经够了，所以微软就设计出这种方案的通用做法，这种方案对于每一个操作不做控制，只是在程序中根据角色对是否具有操作的权限进行控制；这里我们就不做详述2.基于操作的权限设计这种模式下每一个操作都在数据库中有记录，用户是否拥有该操作的权限也在数据库中有记录，结构如下：但是如果直接使用上面的设计，会导致数据库中的UserAction这张表数据量非常大，所以我们需要进一步设计提高效率，请看方案33.基于角色和操作的权限设计如上图所示，我们在添加了Role，和RoleAction表，这样子就可以减少UserAction中的记录，并且使设计更灵活一点。
但是这种方案在用户需求的考验之下也可能显得不够灵活够用，例如当用户要求临时给某位普通员工某操作权限时，我们就需要新增加一种新的用户角色，但是这种用户角色是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工权限时删除此角色，我们需要设计一种更合适的结构来满足用户对权限设置的要求。
4.2,3组合的权限设计，其结构如下：我们可以看到在上图中添加了UserAction表，使用此表来添加特殊用户的权限，改表中有一个字段HasPermission可以决定用户是否有某种操作的权限，改表中记录的权限的优先级要高于UserRole中记录的用户权限。
这样在应用程序中我们就需要通过UserRole 和UserAction两张表中的记录判断权限。
到这儿呢并不算完，有可能用户还会给出这样的需求：对于某一种action所操作的对象某一些记录会有权限，而对于其他的记录没有权限，比如说一个内容管理系统，对于某一些频道某个用户有修改的权限，而对于另外一些频道没有修改的权限，这时候我们需要设计更复杂的权限机制。
系统用户权限授权记录表-模板
该文档旨在提供一个系统用户权限授权记录表的模板，以便记录和管理系统用户的权限授权。
用户信息
权限授权
授权审批历史
注释
- 请在“用户信息”部分填写用户的基本信息，如用户名、用户ID、所属组织和职位。
- 在“权限授权”部分，记录每次权限的授权情况，包括权限名称、描述、授权日期和授权人。
- “授权审批历史”部分用于记录权限授权的审批历史，包括审批日期、审批人和审批意见。
该模板可以根据实际需要进行调整和自定义，以满足具体的权限授权记录需求。
权限设计方案权限管理设计一•博客分类：•设计设计模式数据结构应用程序权限设计我们在开发系统的时候，经常会遇到系统需要权限控制，而权限的控制程度不同有不同的设计方案。
1. 基于角色的权限设计这种方案是最常见也是比较简单的方案，不过一般有这种设计已经够了，因此微软就设计出这种方案的通用做法，这种方案对于每一个操作不做控制，只是在程序中根据角色对是否具有操作的权限进行控制；这里我们就不做详述2. 基于操作的权限设计这种模式下每一个操作都在数据库中有记录，用户是否拥有该操作的权限也在数据库中有记录，结构如下：可是如果直接使用上面的设计，会导致数据库中的UserAction 这张表数据量非常大，因此我们需要进一步设计提高效率，请看方案33. 基于角色和操作的权限设计如上图所示，我们在添加了Role，和RoleAction表，这样子就能够减少UserAction中的记录，而且使设计更灵活一点。
可是这种方案在用户需求的考验之下也可能显得不够灵活够用，例如当用户要求临时给某位普通员工某操作权限时，我们就需要新增加一种新的用户角色，可是这种用户角色是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工权限时删除此角色，我们需要设计一种更合适的结构来满足用户对权限设置的要求。
4. 2,3组合的权限设计，其结构如下：我们能够看到在上图中添加了UserAction表，使用此表来添加特殊用户的权限，改表中有一个字段HasPermission能够决定用户是否有某种操作的权限，改表中记录的权限的优先级要高于UserRole中记录的用户权限。
这样在应用程序中我们就需要经过UserRole和UserAction两张表中的记录判断权限。
到这儿呢并不算完，有可能用户还会给出这样的需求：对于某一种action所操作的对象某一些记录会有权限，而对于其它的记录没有权限，比如说一个内容管理系统，对于某一些频道某个用户有修改的权限，而对于另外一些频道没有修改的权限，这时候我们需要设计更复杂的权限机制。
管理员后台权限的设计和配置一、设计在PRolePermissionAction表中通过当前用户所具有的角色ID找到用户所对应的角色所具有的操作权限列表，通过当前所请求的页面的URL在用户的角色所对应的操作权限列表中是否存在，来判断当前用户对该页面所具有的权限，该方法控制到页面级是完全可以的但是要想具体到操作级别除非页面的Action跟页面不是同一个页面才可以（此设计的不足之处在于要想控制到操作级别Action和Page不能是同一个页面，还有就是每个菜单必须首先要配一个浏览的操作）。
管理员后台跟权限有关的表有以下几个：3. PModule：模块表（此表需要手动去维护，左侧的菜单来源于这个表，每新增加一个模块，需要把模块的信息维护到这个表中）4. PermissionAction：模块操作表（每个模块下的操作的拆分，此表需要手动维护，每新增加一个模块，需要把模块下的所有操作拆分开来，然漂友会后维护到这个表中，以便角色管理时给对应的角色分配相应的操作权限）5. PRolePermissionAction：角色权限表（给每个角色分配不同的操作权限，这个表通过角色管理来维护）二、配置（拿公共类管理里的角色管理举例）1.在PModule中手动维护角色管理的信息如下图：目前只支持到三级菜单，父级菜单无需配置ModuleUrl，最后一级菜单才需要ModuleUrl。
配置好后左侧菜单就会出现角色管理那一项。
如果是超级管理员的话就可以访问角色管理的页面了。
2．将角色管理页面上的操作拆分，并维护PermissionAction表，如下图：每一个的菜单所对应的页面，必须配置一个浏览操作，如果不配置的话普通管理员是访问不了该页面的，如上图所示将角色管理拆分出来了三个操作，配置完后角色管理的添加和修改操作中就可以看到刚才配置的信息了，如下图：2.给相应的角色配置角色管理的操作权限：选中需要的操作，点确定即可，这样就在PRolePermissionAction表中保存了该角色所具有的操作权限了。
权限管理表设计权限管理表主要记录用户的权限信息，包括用户的角色、菜单、操作和资源等。
具体的表设计如下：用户表（user）- 用户ID（user_id）：主键，用户的唯一标识- 用户名（username）：用户的登录名- 密码（password）：用户登录的密码- 姓名（name）：用户的真实姓名- 手机号（phone）：用户的联系电话- 邮箱（email）：用户的邮箱地址角色表（role）- 角色ID（role_id）：主键，角色的唯一标识- 角色名称（role_name）：角色的名称- 角色描述（role_description）：角色的描述信息用户角色关系表（user_role）- 用户角色关系ID（user_role_id）：主键，用户角色关系的唯一标识- 用户ID（user_id）：外键，关联到用户表的用户ID- 角色ID（role_id）：外键，关联到角色表的角色ID菜单表（menu）- 菜单ID（menu_id）：主键，菜单的唯一标识- 菜单名称（menu_name）：菜单的名称- 菜单路径（menu_path）：菜单的访问路径角色菜单关系表（role_menu）- 角色菜单关系ID（role_menu_id）：主键，角色菜单关系的唯一标识- 角色ID（role_id）：外键，关联到角色表的角色ID- 菜单ID（menu_id）：外键，关联到菜单表的菜单ID操作表（operation）- 操作ID（operation_id）：主键，操作的唯一标识- 操作名称（operation_name）：操作的名称菜单操作关系表（menu_operation）- 菜单操作关系ID（menu_operation_id）：主键，菜单操作关系的唯一标识- 菜单ID（menu_id）：外键，关联到菜单表的菜单ID- 操作ID（operation_id）：外键，关联到操作表的操作ID资源表（resource）- 资源ID（resource_id）：主键，资源的唯一标识- 资源名称（resource_name）：资源的名称- 资源路径（resource_path）：资源的访问路径角色资源关系表（role_resource）- 角色资源关系ID（role_resource_id）：主键，角色资源关系的唯一标识- 角色ID（role_id）：外键，关联到角色表的角色ID- 资源ID（resource_id）：外键，关联到资源表的资源ID通过以上表的设计，可以实现对用户权限的管理。
任何系统都离不开权限的管理,有一个好的权限管理模块,不仅使我们的系统操作自如,管理方便,也为系统添加亮点。
●不同职责的人员，对于系统操作的权限应该是不同的。
优秀的业务系统，这是最基本的功能。
●可以对“组”进行权限分配。
对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。
所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。
●权限管理系统应该是可扩展的。
它应该可以加入到任何带有权限管理功能的系统中。
就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。
●满足业务系统中的功能权限。
传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。
针对OA系统的特点，权限说明：权限在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。
将模块与之组合可以产生此模块下的所有权限。
权限组为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。
比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。
角色权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。
用户组将某一类型的人、具有相同特征人组合一起的集合体。
通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。
用户组的划分，可以按职位、项目或其它来实现。
用户可以属于某一个组或多个组。
通过给某个人赋予权限，有4种方式(参考飞思办公系统)A.通过职位a)在职位中，职位成员的权限继承当前所在职位的权限，对于下级职位拥有的权限不可继承。
权限表设计2009-09-21 16:14最简单的权限验证，应该是登录态的验证，如果登录，则可以怎样，没有登录，则不能怎样：if ($isLogin === true) {//do something} else {//do nothing}一般使用会话或者Cookie来保存登录态，具体实现不在此文讨论范围。
一般权限都和人挂勾，首先识别你是谁，然后看你有能力做什么，然后再确认你的能力在这个地方是否可以使，一个权限验证算是基本上完成。
我们围绕这几点来看权限如何去设计。
首先要能识别操作者是何许人，我们需要一张保存操作者信息的表，也就是通常所说的用户表。
简单的用户表如下：CREATE TABLE user (userId int(10) unsigned NOT NULL,username varchar(255) NOT NULL,PRIMARY KEY (userId))一般使用一个用户ID来标识一个唯一的用户，可以使用数字，或者直接使用用户名作为主键(如果用户名不重复)。
这里我们使用userId来唯一标识一个用户。
有了用户以后，接下来需要确认这个用户所具有的能力，也就是权限，那么首先我们需要列一下我们的系统总共需要几个权限，比如增、删、改、查等。
增加一张权限表：CREATE TABLE permission (permissionId int(10) unsigned NOT NULL ,permissionName varchar(255) NOT NULL ,PRIMARY KEY (permissionId))同样的我们以permissionId作为主键来唯一标识一个权限，当然也可以使用permissionName来标识(如果你能确定唯一的话)。
我们新增几条记录在这张表里：+--------------+----------------+| permissionId | permissionName |+--------------+----------------+| 1 | add || 2 | del || 3 | modify || 4 | select |+--------------+----------------+这里列举了4个权限，简单的表示我们的用户在系统里可能具有的增、删、改、查4种不同的能力。
接下来把这些能力赋给用户，需要一张对应表来保存：CREATE TABLE userPermission (userId int(10) unsigned NOT NULL,permissionId int(10) unsigned NOT NULL,PRIMARY KEY (userId, permissionId))其中将userId和permissionId设置为主键，表示某个用户具有某种权限。
表内容可能如下：+--------+--------------+| userId | permissionId |+--------+--------------+| 1 | 1 || 1 | 4 || 2 | 1 || 2 | 2 || 2 | 3 || 2 | 4 |+--------+--------------+以上权限配置表明用户1具有增、查权限，用户2具有增、删、改、查权限(嗯可以猜想用户1是个普通用户，用户2是个管理员)。
写到这里，我发现基本的用户权限系统雏型已经完成了。
这么简单？看起来好像确实就是这么简单。
一个用户拥有哪些权限，那么只需要勾选相应的权限分配给这个用户。
在验证权限的时候，取出用户所拥有的所有权限，然后判断是否存在该权限即可。
实际上的权限设计要比这个复杂一些，到底复杂在哪里呢？我们接下来分析。
当用户比较多而且权限数量比较多的时候，你是不是要每个用户都去勾选一堆权限呢？如何简化这个操作？OK，用户组的概念推出。
所谓用户组，就是具有某些权限的一类人的集合。
我们赋予用户组某些权限(角色表)，然后把这个用户加到这个用户组里即可，来看看用户组长什么样子：CREATE TABLE group (groupId int(10) unsigned NOT NULL,groupName varchar(255) NOT NULL,PRIMARY KEY (groupId))和用户表类似，我们需要标识一个唯一的组，这里分配一个组ID作为主键来标识。
内容可能如下：+---------+-----------+| groupId | groupName |+---------+-----------+| 1 | user || 2 | admin |+---------+-----------+有了用户组表后，我们需要把一些权限赋给用户组，就需要一张用户组权限表：CREATE TABLE groupPermission (groupId int(10) unsigned NOT NULL,permissionId int(10) unsigned NOT NULL,PRIMARY KEY (groupId, permissionId))我们分配增、查权限给user组，分配增、删、改、查权限给admin组：+---------+--------------+| groupId | permissionId |+---------+--------------+| 1 | 1 || 1 | 4 || 2 | 1 || 2 | 2 || 2 | 3 || 2 | 4 |+---------+--------------+用户组表和用户组所对应的权限表有了，那么要把用户分配给一个用户组，就需要一张用户和组的对应关系表：CREATE TABLE userGroup (userId int(10) unsigned NOT NULL,groupId int(10) unsigned NOT NULL,PRIMARY KEY (userId, groupId))把用户1赋给user组，把用户2赋给admin组，和一开始我们直接分配权限一样：+--------+---------+| userId | groupId |+--------+---------+| 1 | 1 || 2 | 2 |+--------+---------+很明显这里的配置信息相对比userPermission表少很多，这里只需要记录用户属于什么组就可以了，那么检测用户权限，就需要查出用户所在的组，然后再查出这个组(或者这些组)所拥有的权限，就可以得出用户所具备的权限，再进行验证即可。
当然会比直接查询userPermission 表绕一点点，不过相对比维护成本，这点点消耗不算什么。
更何况我们其实仍然可以保存userPermission表，在分配用户组的时候，同时更新userPermission表即可。
这里可以看到，除了在分配用户权限方便以外，当你需要更改某类用户权限的时候，你只需要更改其所在组的权限，那么这个组下所有成员的权限也会随之更改，非常方便。
到这里用户、用户组的权限构成基本完成。
它能解决大部分问题，可是我发现它仍然有一些小的问题。
比如如果某个用户只有查权限，我不得不再新增一个用户组，搞得用户组也很多，怎么办呢？如果这个用户属于普通用户组，其实可以考虑也分配普通用户组给这个用户，然后再从普通用户组里“扣掉”增权限。
要达到这样的效果，怎么处理呢？其实很简单，我们刚才没有去掉的userPermission表派上用场，这个表存储了用户的实际单个权限，我们只需要增加一个字段标识用户是拥有这个权限，还是没有这个权限即可，这样可以解决两个问题：一是从现有用户组中扣掉某些权限，二是在现有用户组中，再给这个用户增加用户组以外的权限。
来看一下userPermission表：CREATE TABLE userPermission (userId int(10) unsigned NOT NULL,permissionId int(10) unsigned NOT NULL,has enum('yes','no') NOT NULL,PRIMARY KEY (userId, permissionId))把用户1的增权限去掉，那么内容可能像这样：+--------+--------------+-----+| userId | permissionId | has |+--------+--------------+-----+| 1 | 1 | no || 1 | 4 | yes || 2 | 1 | yes || 2 | 2 | yes || 2 | 4 | yes || 2 | 3 | yes |+--------+--------------+-----+这个用户依然在user组里，只不过user组所拥有的2个权限(add, select)，他少了个add(ID 为1被标记为no)权限而已。
嗯，这样做有解决了这个小问题，不过这个功能增强会让分配权限代码更复杂一些，不仅要给用户分配组，还可能需要操作具体权限，让他有或者让他没有相应的权限。
OK，简单的权限设计全部完成，只不过，细心的读者，你是否意识到，还少点什么呢？没错，即使到这里，整个权限验证还少了一块很重要的部分，那就是用户拥有这些权限，那么他能在哪里使用这些权限。
考虑一个例子，一个论坛版主在他所管理的论坛版块里拥有删、改帖子的权限，他在其他非他所管理的版块就没有这些权限，可能在其他论坛版块他像是一个普通用户一样，我们上面讨论的权限设计如何做到这个验证呢？那么我个人觉得，权限设计到上面已经完成了，接下去这种情况，属于业务逻辑层的验证，我们从权限系统中已经获得用户的权限，那么在具体业务逻辑中，和权限进行绑定即可，以上例子可以用一个版块用户关系表来解决这个问题：CREATE TABLE userBoard (userId int(10) unsigned NOT NULL,boardId int(10) unsigned NOT NULL,PRIMARY KEY (userId, boardId))标记用户拥有哪些版块的管理权限，那么在严重用户拥有管理权限的时候，还要看当前版块是否是用户管辖内的版块，最终确定用户是否有操作权限。
那么我将这类和业务逻辑相关的权限分配归到用户角色里，同样可以创建一系列角色，来管理用户所管辖的范围，比如超级版主，他也是具有管理删、改权限，只不过他的权限作用于全论坛，那么普通版主就需要指定论坛，这样来区分用户组和角色组我想会使整个权限系统更加清晰。
到这里，权限验证全部完成，以上没有具体实现代码，我相信这样已经足够了，具体的实现代码和业务逻辑由具体的应用实现吧。
