请问各位牛人，关于权限问题的数据库设计问题。复杂内详，非牛人勿进。

Question

要设计一个论坛，有
用户，论坛板块，文档 和权限 几个要素。具体问题是。
先说，简单的。
板块。
就是论坛的各个板块，1-N个。 N不定。用户和权限。
论坛中存在有5种角色。
Role_S1 Role_S2 Role_A Role_B Role_C
其中前2种是跨板块的角色，也就是无视板块，类似管理员的角色。并且对于每个论坛板块，1个用户可以拥有多个角色，理论上是1-5个角色。
这点类似windows，某用户是User同时可以是Administrator。
虽然上面的例子，User有点多余。
但是由于有Role_A Role_B Role_C的存在，所以这样的要求是合理的。
也就是用户可以只是A，也可是同时是A和B。相反，同一个用户在不同的板块可以是不同的角色。（其实Role_S1 Role_S2例外）
比如，某用户可以是在板块B_1里是Role_A，
但是在板块B_2里就只是Role_C。另外，角色权限高的用户，可以给权限低的赋予某些权限。文档
对1个板块，会有5种文档。
D_1, D_2, D_3, D_4, D_5
不同角色的用户，对于5种文档的访问权限不一样。图里没写清楚的是，那个权限访问的表格是针对某个板块的。
即，由于Role_S1可以更改那个表格，每个板块的权限表格可能不同。比较复杂的权限，我想根据上面的要求，数据库结构怎么设计呢？最后和大家说下对不起，标题只是想吸引更多人进来，没有对大家不敬的意思。

Answer 1

sccb 最近总是有一些很有意思的问题啊。我想了下：如果要用接近标准的模型来处理的话，会需要引入“数据权限”和“岗位”，但这么一来体系结构就太复杂了，对于一个论坛型系统整成这样子，似乎有些小题大作。无论如何先介绍下数据权限和岗位吧：
Role-Base模型，也就是：用户 -- 角色 -- 权限，这个体系是功能型权限管理的基础，这里假定已经理解。
◎ 数据权限则是指，某个用户对某项数据的控制权力，比如：
甲、乙 两个人都具有：“删除帖子”这个功能的使用权力，但甲只能删除“Java板块”，而乙只能删除“.Net”板块。这种其实就是相等功能权限基础上，各自权力的作用范围不同，即“数据权限”。
◎ 为了引入数据权限，需要能将数据权限跟功能权限挂钩，因此又引入了“岗位”：
此时，用户不再直接跟角色挂钩，而是只能跟岗位挂钩了：用户 <-1--N-> 岗位
而岗位则可捆绑角色和数据权限：角色 <-N--N-> 岗位 <-N--N-> 数据权限
◎ 那么由此形成的关系大致是：
  甲：Java板块版主岗：Java板块数据权限（FormID） + 版主角色（RoleID）
  乙：.Net板块版主岗：.Net板块数据权限（FormID） + 版主角色（RoleID）
因为甲兢兢业业，所以荣升为超级版主：
  甲：超级版主岗：根板块数据权限（FormID:0） + 版主角色（RoleID）
因为乙工作太忙，经历顾不过来，只能管理ASP和VB.Net，所以申请调级：
  乙：ASP版主岗＋VB版主岗：ASP + VB板块数据权限（FormID×2）+ 版主角色（RoleID）
  
 
先介绍下情况，等想到有其它建议再续

Answer 2

继续补充点点。关于：“对1个板块，会有5种文档”
个人建议是直接将5种文档及其对应操作都转为权限就行了；因为数据权限更适合于那种存在“父子关系”的控制，也就是：根板块 > 主板块 > 子板块 > ...
最后给点关于实体关系的建议，考虑在数据权限层面做了点化简：
用户 <--> 用户角色 <--> 角色 <--> 角色权限 <--> 权限
用户：UserID、Name、...
用户角色：UserID、RoleID、FormID
角色：RoleID、RoleName
角色权限：RoleID、PermissionID
权限：PermissionID、Description

Answer 3

有点复杂，给你分析下
(1)你必然会有一张用户表User(user_id,……)和一张论坛版块的表Board(board_id,……)(2)你有5种角色，不知道你这个5种是否是固定的（会不会可能以后有6种，7种？），这里假设是固定的5种，如果不是固定的，那么你还需要一张role表来存放角色
按你的说明，用户和版块是多对多的权限关系（1~5个角色映射N个版块），所以这个需要一张表User_Board_Role(user_id,board_id,role,……),字段role就是你的Role_S1 Role_S2 Role_A Role_B Role_C(3)对于每一个版块，你每个角色的权限不同，而且是可以更改的，这个是固定的1～5的映射，因此你甚至可以把5个角色的权限都放到Board表中，但为了以后的扩充性，不建议你这么做，因此建议你新建一张Board_Authority(board_id,role,authority)，字段authority考虑到你的需求应该是一个权限字，比如设置为32位int，对每种类型文档用4个bit位来表示不同权限，RW:1000 R:0100 x:0010 -:0001 32位整数可以表示8种文档，满足你要求的5种文档的需求，比如你表中Role_S2的权限用二进制位表示就是1000,1000,1000,0100,0000。 这样设计的好处是你可以用“或”操作获得用户的真实权限，比如查询用户在版块A的权限，你通过用户id检索到用户在该版块的角色，比如是Role_A 和 Role_B，然后检索Role_A Role_B在版块A的权限字Authority_A Authority_B，那么用户的最终权限是Authority_A|Authority_B，获得用户权限后判断用户有没有某种权限只要按位与一下后比较一下就行了，比如对D_1有没有R的权限，只要与1111,0000,0000,0000,0000按位&后获得最高的4位然后与D1的读权限位0100,0000,0000,0000,0000比较下大小即可(大于等于即代表该用户有这个权限，权限位可以预先定义为常量)

Answer 4

不知道我的理解对不对
以前做过个类似的系统
是一个教学管理系统
就是有各种教师，比如数学，英语
然后教师都有查看学生分数或者修改的功能
但是对于不同教师，可查看学生分数的科目也不同
比如数学老师只能查看和修改数学的科目，英语不可查看和修改而我们的做法，就是和ldh911说的差不多
分为数据权限和功能权限2种
功能权限就是传统的做法，把查看和修改权限赋给各个教师角色
然后不同的用户再赋予不同的教师角色
然后就是数据权限
就是数据所属的类型（比如数学英语），ROLEID
然后操作的时候就是
分别用该用户的ROLEID去查询功能权限表，看是否有查看和修改功能
查看数据权限表，是否有该数据的拥有权限然后就是应用到LZ所说的这里
就是，功能权限表，比如R/W,R,X,-，然后赋给不同的角色
然后就是数据权限表，比如D_1，D_2,也是同样赋给不同的角色
然后角色再赋给用户
当进行操作的时候，就是同时需要查这2张表只是个人建议和理解，如有错误请指出
因为以前碰到过类似的所以是这样做的
希望其他人能有更好的解决方法，来供学习

Answer 5

说的通俗一点  我前几天刚弄掉一个小的erp礼品库的系统、  
我就在做权限我想说可以先确定设计 在每个用户设置一个
外键对应到一张权限表中  、表中除了auid的权限ID   
后跟一个权限的字段  存char类型字串 以|隔开 这样的话
权限分配的话拿出来可以确认他到底是有何种权限、
然后对应不同的操作、问题是这样的操作不是很复杂但是比较拖累
可能有些不合适  、 scbb你再考虑考虑 如果有更好的方式 
一起考虑下

Answer 6

好处就不说了，主要谈谈局限性：
  违反数据库设计的 第一范式（1NF）。
  更主要的是：如果碰到数据集层面的权限关联运算，索引就没法用了。
设计数据模型时，必须进行“关键需求验证”，比如（举例，未必符合实际需求）：
◎ 版主选择出所有管辖权范围内需要审批的帖子；这种情况下往往需要跟数据权限进行关联运算；
◎ 用户选择出所有可访问板块的可读的最新帖子；值得注意的是 Role_C 他在5种帖子中只能看到2种；也是关联运算。
◎ 帖子发生了移动，对权限控制是否存在影响？子板块发生移动，对权限控制是否存在影响？是否可修正？如果所设计的数据模型，在进行需求验证过程中，存在性能问题（无法使用索引、超级多表连接），那么基本上就意味着该数据模型是不可行的。如果说根本实现都实现不了该需求，那就直接拍死了。所以，“设计”某个东西，不是仅就想出一种可行做法这么简单。

Answer 7

那么可以初始论坛权限设计想好  然后可以建张权限表啊  - -  id
对应的权限内容  、 后台自己写的么  当然知道应该如何控制、
scbb   ldh911 你俩也想想看  我是刚做完一个礼品库的 
但是权限设计没有那么复杂 、  一起想想 网上有开源的论坛项目
他们那种没有对应的权限方式么 ？

Answer 8

负责程度是根据“需求”来的，必要时可以牺牲20%需求以更好地满足80%的需求。比如：很常见的就是 牺牲一定的实时性 以满足 更高的性能要求。传统情况下，RoleBase模型就已经能解决大部分问题；剩下的就是你选择变通 还是 牺牲。

Answer 9

目前为止是这个意思  、 公司马上做一个DRP的项目  我这抹不清头脑、
最近真心比较晕 我工作才2个月多、 自己还在看spring 等框架技术、
做的项目比较乱  一起交流下  有利于工作开发  ldh911

Answer 10

非常欢迎探讨啊，互相进步。P.S. 发现前面写了错别字：负责程度 -> 复杂程度

Answer 11

典型技术宅么  、   我是出入茅庐啊 
感觉水很浑   加QQ把 791574896 我发现csdn论坛没法加好友
报404

Answer 12

根据我失败的经历....个人觉得role和permission应该分离，因为如果之后需要扩展，role需要极大的能动性
并且你这个需要里role更像是group，只是特殊在group是在board层面上的而不是forum层面的，需要一个表将三者链接起来既 user， role， board是不是可以用acl。因为个人觉的对于一个论坛acl是比较好的选择，因为更细致
你的要求里，权限设置都是在role这个级别上，并没有要求user级别，如果你的权限分为 read write search (我觉得是不是缺了一个create， 但可能你只需要write权限既能创建，不知道)， 如果将每个board作为一个element，则每个role+board+perm形成一个ace，
用acl的好处，是如果万一将来需要将权限细化到文章级别，细化到用户级别，你的数据结构无须变化，可能需要增加几个perm但是总体的架构已经有了
对于acl的实现，java里面没用过，最近在用php symfony2里的，觉得设计的相当不错，如果到时候真的需要可以看看，如果需要我也可以给你看看他的数据库结构