1.1前言
权限管理系统的应用者应该有三种不同性质上的使用，
A,使用权限 B,分配权限C,授权权限
1.2初步分析
用户和角色
说到权限管理，首先应该想到，当然要设计一个用户表，一个权限表。这样就决定了一个人有什么样的权限。
做着做着就会发现这样设计太过繁琐，如果公司里面所有员工都有这样的权限呢，每一个人都要配置？那是一件很痛苦的事情。因此再添加一个角色表，把某些人归为一类，然后再把权限分配给角色。角色属下的用户也就拥有了权限。
用户、角色之间的关系是一个用户可以对应多个角色，一个角色可以对应多个用户。多对多关系。
所以需要一个中间表，相信大家都很熟悉，自然不会有疑问。
应用场景
有了用户和角色以后，就需要设计应用场景，比如一个应用程序有几大模块（系统模块、项目管理模块、销售模块），
类似这样的模块就是一种应用场景，常见的还有 菜单 、 操作 等等。
假设现在我们设计好了，应用场景包括 模块、菜单、和操作，那么应该有以下六种关系
1. 一个用户可以对应多个模块，一个模块可以对应多个用户。多对多关系。
2. 一个用户可以对应多个菜单，一个菜单可以对应多个用户。多对多关系。
3. 一个用户可以对应多个操作，一个操作可以对应多个用户。多对多关系。
4. 一个角色可以对应多个模块，一个模块可以对应多个角色。多对多关系。
5. 一个角色可以对应多个菜单，一个菜单可以对应多个角色。多对多关系。
6. 一个角色可以对应多个操作，一个操作可以对应多个角色。多对多关系。
这样设计看起来没什么问题。是的，如果没有加入新的关系的话，这样是已经可以满足大部分的需求了。可是如果就是如果，新的关系（需求）往往会加入到系统进来。这个时候就需要再建立一个新的表。系统的复杂度也随着增加。
可以看出，这样的设计有几个问题：
1. 数据表设计太复杂
2. 应对系统方案过于固定
1.3一般的权限模型
用户,角色表，资源表之间是多对多的关系，这样的设计也可以实现权限但是会给t_resource和t_resource_role这张表随着系统中人员的增加数据量将会越来越多，不方便查询。
1.4把问题简单化后的权限模型
不同的应用场合，你可能会想出不同的需求，提了一个新的需求以后，可能会发现原来的设计没方法实现了，于是还要添加一个新的表。这也是上面所提到的问题。
其实不必想得那么复杂，权限可以简单描述为：
某某主体 在 某某领域 有 某某权限
1，主体可以是用户，可以是角色，也可以是一个部门
2， 领域可以是一个模块，可以是一个页面，也可以是页面上的按钮
3， 权限可以是“可见”，可以是“只读”，也可以是“可用”(如按钮可以点击)
其实就是Who、What、How的问题，权限模型如下图所示。
转载请注明：www.xujin.org或www.virgocloud.com