1． 什么是权限？？
l 很多人理解的权限就是用户的登录限制，但事实上权限可能涉及到的远不止如此而已，权限就是在请求我们系统的一个服务(请求地址，请求方法，请求Action，请求WebService等)的时候，当在请求之前的时候我们先要去校验你这个用户有没有访问当前这个请求的权力，如果你有这个权力的话，我们就让你访问，否则你访问不了这个请求。
2． 基于角色的设计
权限里面最重要的实体也就只有三个(用户，角色，操作)，他们之间最重要的也就是实体的关系，如果我们把他们三个之间的关系弄清楚了，权限这个模块你基本就算搞定了。
（一个人可以有多个角色，一个角色可以被多个人拥有），怎么来体现是多对多的关系呢，我们只能加一个中间的关联表。那么表结构如下：
这种设计方案的缺点就是权限控制力度小，如果时间长的话中间表会变得很庞大，很冗余，权限控制不精确。
3． 基于操作的设计
(1)什么是操作的设计呢？就是把我们系统里面的每一个动作都抽象出来抽象成一个操作(Action)，当我们点击某一个按钮的时候就是一个操作，一个动作，只要是我们对网站（或者系统）做任何的操作就是一个动作(Action)，那么这个动作我们当前的用户有没有权力去操作，只有当动作和用户关联起来了，就允许我们去访问这个动作。
(2)如果按照上面这种设计的话，那么我们的动作将会非常的多，如果一个稍微大点的系统的话，那么这个动作就不知道多到哪里去了，这样的话我们的Action这张表的数据就会非常的大，这样还是不会达到我们的需求的，这种设计模式的表结构如下：
4． 基于角色-操作的设计
(1)通过4的设计方案我们能够感觉到如果那样设计的话Action这张表的数据将会非常的大，那么我们能不能针对这个问题解决一下呢，当然是可以的，我们可以对这个动作（Action）再进行一次分组，这时候我们就提出来了角色，那么角色是怎么一回事呢，请继续看。
(2)角色：只要你创建一个角色，这个角色就会关联一组动作，那么如果只要用户加入这个角色，那么这个角色关联的所有动作是不是用户也都具有了呢，也就是你都可以去访问这个角色下面关联的这组动作。所以角色也可以说成是动作的分组。
(3)那么我们把角色和操作柔和到一块，这种设计方式的表结构如下：
5． 将4和5组合起来的权限设计
(1)上面基于角色-权限的设计可能大部分时候已经可以很好地满足系统的需求了，但是在面对某些复杂的、大型的系统时可能还不够完美，例如比如说一个内容管理系统，对于某一些频道某个用户有修改的权限，而对于另外一些频道没有修改的权限，这时候我们需要设计更复杂的权限机制
(3)这个权限是在用户和动作上面又加了一张表，这张表就是用户的特殊权限表，在前面的设计中我们用户和权限关联是通过角色来关联的(可以看第5种方法)，而现在我们用户和动作之间又有了一张动作表。那么这种设计方式的表结构如下：
我们可以看到在上图中添加了UserAction表，使用此表来添加特殊用户的权限，改表中有一个字段HasPermission可以决定用户是否有某种操作的权限，改表中记录的权限的优先级要高于UserRole中记录的用户权限。这样在应用程序中我们就需要通过UserRole和UserAction两张表中的记录判断权限。