咱们在开发系统的时候，常常会遇到系统须要权限控制，而权限的控制程度不一样有不一样的设计方案。html
1. 基于角色的权限设计数据库
这种方案是最多见也是比较简单的方案，不过一般有这种设计已经够了，因此微软就设计出这种方案的通用作法，这种方案对于每个操做不作控制，只是在程序中根据角色对是否具备操做的权限进行控制；这里咱们就不作详述
post
2. 基于操做的权限设计spa
这种模式下每个操做都在数据库中有记录，用户是否拥有该操做的权限也在数据库中有记录，结构以下：设计
可是若是直接使用上面的设计，会致使数据库中的UserAction这张表数据量很是大，因此咱们须要进一步设计提升效率，请看方案33d
3. 基于角色和操做的权限设计orm
如上图所示，咱们在添加了Role，和RoleAction表，这样子就能够减小UserAction中的记录，而且使设计更灵活一点。htm
可是这种方案在用户需求的考验之下也可能显得不够灵活够用，例如当用户要求临时给某位普通员工某操做权限时，咱们就须要新增长一种新的用户角色，可是这种用户角色是没必要要的，由于它只是一种临时的角色，若是添加一种角色还须要在收回此普通员工权限时删除此角色，咱们须要设计一种更合适的结构来知足用户对权限设置的要求。对象
4. 2,3组合的权限设计，其结构以下：blog
咱们能够看到在上图中添加了UserAction表，使用此表来添加特殊用户的权限，改表中有一个字段HasPermission能够决定用户是否有某种操做的权限，改表中记录的权限的优先级要高于UserRole中记录的用户权限。这样在应用程序中咱们就须要经过UserRole和UserAction两张表中的记录判断权限。
到这儿呢并不算完，有可能用户还会给出这样的需求：对于某一种action所操做的对象某一些记录会有权限，而对于其余的记录没有权限，好比说一个内容管理系统，对于某一些频道某个用户有修改的权限，而对于另一些频道没有修改的权限，这时候咱们须要设计更复杂的权限机制。
5. 对于同一种实体（资源）用户能够对一部分记录有权限，而对于另一些记录没有权限的权限设计：
对于这样的需求咱们就须要对每一种不一样的资源建立一张权限表，在上图中对Content和Channel两种资源分别建立了UserActionContent和UserActionChannel表用来定义用户对某条记录是否有权限；这种设计是能够知足用户需求的可是不是很经济，UserActionChannel和UserActionContent中的记录会不少，而在实际的应用中并不是须要记录全部的记录的权限信息，有时候可能只是一种规则，好比说对于根Channel什么级别的人有权限；这时候呢咱们就能够定义些规则来判断用户权限，下面就是这种设计。
6. 涉及资源，权限和规则的权限设计
在这种设计下角色的概念已经没有了，只须要Rule在程序中的类中定义用户是否有操做某种对象的权限。
以上只是分析思路，若是有不对的地方，请你们指正。
来源：http://www.cnblogs.com/yukaizhao/archive/2007/04/15/user_role_action_permission.html