数据权限是基于角色还是用户?

目前数据权限的大概需求如下:
 监督员默认只可以看见自己的数据,但经过授权后可以看到其他监督员的数据
 A部门部长默认只能看到A部门的数据,但经过授权后可以看到其他部门的数据
 分管领导只能看到分管部门的数据
 站长可以看到所有的数据

目前我的做法是基于用户的,使用ACL来做的。
就是会建立一张ACL表,记录数据授权情况。如：

acl表

id userId principalId principalType
1 zhangsan zhangsan person
2 zhangsan lisi person
3 zhangsan dept1 department

上面的数据表示
zhangsan这个人可以看到自己、李四和dept1这个部门的数据。
然后提供一个授权界面,界面原型大概如下：

    自己 
    用户----->弹出人员列表
    部门----->弹出部门列表
    所有

这样的话,系统管理员就可以勾选自己、某个人、某个部门的形式来给用户进行数据授权。授权的情况就
存放到ACL表中去。

我问的是：
第一、我上面的基于用户的做法可以做到吗?有什么致命缺陷没?
第二、数据权限一般来说是基于角色还是用户的。基于角色的有什么好处?

1、你的做法可以实现功能，但是如果授权复杂，DB存储的数据量会较大；
2、授权一般基于角色，因为真实的业务场景，大多是很多人属于同一角色，对角色授权，就不用对属于同一角色的用户依次授权，使用更加方便，维护也方便，后台DB数据量也相对较小。

基于角色控制是比较好的，这样，但某个人调岗后，只需要改变他的角色就可以改变他的访问权限

同时如果要临时加权限的话，可以增加临时角色，专门针对这个人角色

应该是基于策略，不应该是基于用户或者角色。

因为基于用户，那么设置起来就太复杂了，而且维护量大。
基于角色的话，对于有些系统能搞定，维护量也有那么大，代码里面也有很多判断工作。比如总公司人力资源经理，分公司人力资源经理（有的时候还要拆分为北京分公司人力资源经理、上海分公司人力资源经理.....）可见复杂度。

建议使用开源软件ralasafe， http://www.ralasafe.com/zh 国产的开源中间件，而不是框架，对你的应用和数据库都没有要求。在银行和电信都有应用案例。

基于用户做如果系统控制的数据比较多，那么会崩溃的。这个表的数据量会非常的巨大。而权限基本上又是最常用到的数据了， 这样会引发一系列的性能问题。

建议楼主使用权限来做。另外还需要引入组织的概念。
给你下面这个模型。
1. 企业的所用的数据本身有一个所述。比如一个单子A是部门1的，单子B是部门2的。将单子看做资源，那么部门相当于这个资源的所属。

  1. 一个企业通常有其组织架构例如： 国家 公司 部门。 这里有个继承关系。 一个国家中有多个公司，公司中有多个部门。

  2. 第三个是角色的感念： 一个部门中的数据，可能有的是给Account 看的， 有的是给HR看的，有的是给Manager看的， 有的是所有员工都可以看的。

  3. 级别员工A是公司的Manager，那么他应该可以查看公司下所有BU的数据。一个员工BU级别的Manager可能同时管理了多个BU。

表结构：
一个User表
一个Role表： 定义Role
一个Organizaiton表： 定义组织结构，注意使用树形结构定义。这样方便权限继承的实现（一个COMPANY级别的ROLE, 继承所有BU节点上的权限）。
一个UserRoleOrganizaiton表： 定义当前用户的Role， 并且指定Role的级别（属于哪个组织节点上的）。

以上是我当时做的一个系统的实现方法。

忘记写Resource相关的内容， 补充下。

还有一个表Resource用于定义数据中需要保护的那些资源。
还有一个ROLE_RESOURCE表定义Role可以访问的Resource。并且追加一个OPERATION的属性。例如ROLE A 可以写Resource1 而不能Read。