对于记录级别的权限控制，大家有没有成功应用？

看到有些实现在提取记录的时候就用子查询把结果选择出来，有的使用提取后过滤的方式。

对于第一种方法不太容易修改，但是利用了数据库自身的性能。第二种方式灵活，但是效率低，具体没有做过这种尝试，不太清楚对性能的影响到底多大，是否无法用适当的硬件提升来补偿？

最近需要实现一个这样的功能，大家给点指导意见 ！！ 

我目前是用第一种方式实现的。确实如你所说，
存在不易修改的问题。

第二种方式的问题在于，在极端情况下，
你需要把非常多的数据取出来再进行过滤，存在着
大量的浪费。还有一个很严重的问题是，如何获得
某个用户有权访问的记录条数？总不至于把所有的
记录全部取出再过滤吧？

其实我也想过这个问题,由于时间很忙,所以就没有怎么把框架做出来(现在的手头工作太多了,技术也不太好,好多的问题也没有想清楚).

用第一种方法好是好,但是应该怎么做呢??


我的想法是:
首先在建表的时间不应该建立多余的字段(例如:不用建立roleId,departmentId等字段),因为如果这样做的话,工作量太大,而且以后扩展也真是麻烦..
所以我想找到一个表专门管理这些(例如:roleId,departmentId等),这个表能和其它的表和它的记录ID号相对应(可以说是一个ID字典),如果要查该表的话,就在SQL中再进行拼凑(这是一个拦截器类似的东西),而后就可以获得啦.

但是如果是多表呢??复合ID呢等??
我都还没有想到好的办法去解决.

多多指教,如果是谁做的话,不访共享一下经验,谢谢.

我现在的做法就是建立多余字段，工作量倒不大，问题是
“太死”了，不够灵活。用户的权限模型一变，就可能引起
剧烈的变化

单独一张表，维护用户对各个表的添加删除权限，根据这些权限构造出where语句

维护用户对各个表的添加删除权限，是不足以支持到记录级的控制的。

而且，就算你用这张表来记录每条记录的权限，也存在很多问题。
例如，这张表的记录数=用户数×总记录数，再比如，新增加的用户
应该拥有哪些记录的什么权限，新建记录又能被哪些访问到等等。

权限可以归纳为：什么人在什么时间在什么地方可以对什么对象做什么操作。
我们一般只控制静态的权限，所谓静态，也就是对象和操作是在系统交付时就固定的，例如：新闻删除功能、新闻发布功能之类。
动态权限，我们曾经尝试过，但没找到很好的方式，作出来后，发现还不如业务系统自己控制来得方便，也就是说很难通用。
如果真正控制到每一条记录，可能有点困难，我们一般不会直接控制到数据表本身，而是与之关联的主表或者基础数据表，例如：一般不会将每一条新闻作为一个权限赋予用户，用户想控制的多数是新闻的类别，这样，与用户关联的是类别而不是新闻本身。
这样得到的模型可能是：
权限，包括权限编号、限制条件（例如这里是新闻类别=xxx）、操作类型（增删改crud，实现可以用掩码）、权限类型（新闻类别）。
如果更变态一点的，条件可能会是（从2004-1-1到2004-3-20）的新闻，权限类型就可以叫做新闻时间段之类。
我可能更倾向构造sql的方式，主要还是担心效率问题，如果是构造sql的话，上述权限的数据模型可能得加上对应得表名，而条件则应该保存得是类似sql的条件表达式了。
搞这个东西往往是吃力不讨好，如果系统中只有一两个这样需要动态控制的模块，直接写程序控制就可以了，不必搞什么通用组件，免得老大们说设计过度了。

呵呵，基本上就如mikeho所讲。
   不过我个人觉得，要做到数据行与数据列权限也不是太难的事，上次我做的数据行权限的demo只是mikeho你没有用罢了，呵呵。至于数据列，采用来自于Value Object的思想就更加容易了，有兴趣的朋友可以结合看一下IBM的关于Java动态编程的文章。
    不过最终总结起来，还是如mikeho所讲，权限归功到底是什么对象对什么目标有多大范围多大操作的权限。简单地说，在权限的中有四个概念：对象、目标、范围、操作，把它们分清楚了，要做一个比较通用的权限管理模块还是比较容易的。
    一般来说，对象可以是用户、角色、用户组（尽量不要涉及具体的组织结构），目标包括模块、单、功能、表、数据等等，范围一般就是说的广度，包括组织结构中的广度、表的广度（如schema）等等，操作一般来说也就是增加、更新、删除、读取了。
    基本上来说，它就覆盖了权限需要实现的东东（当然也许有特殊需要）。

上次我做的数据行权限的demo只是mikeho你没有用罢了
不是我不想用，听你说了半天，老大们都不知怎么用，他们说还不如自己写程序控制了。呵呵

唉，他们只是闹腾罢了，白白耗费了我那么久的时间和精力，好不容易搞出来，呵呵，又不用了。真是！
   不过倒是为以后留下了思路