关于用户组和权限的表结构设计

      对于一个有N个管理模块的WEB后台程序,如何为管理员分配权限,又如何在表中体现出来,可能每个人都有自己的实现过程。我作为一个菜鸟,搜集了一些资料,在这里做一下整理。
     前题:五个模块;两个组;几个用户。权限分配。
     我记得我第一次做这个的时候,当然网站比较简单。一张表搞定,用USER_TYPE区分1234为不同的身份组(组的字典表都没有做,程序中用注释体现 ),然后跟着五个字段,由0和1表示这个家伙有没有管理权限。一切按着需求来,0和1的标识对于一个小网站来说已经够用了,其实属于一个假的权限指派,结果大家都想的到,因为对于一个用户来讲他只有可见或不可见两个层面,而不存在可管理不可管理的真实权限。当然BOSS不知道,而我为了防止敲URL地址直接访问,不得不在每个页面都做验证。虽说骗过了BOSS,真正悲剧的在于以后模块的越来越多,每加一个模块我就得跟加一个字段,这应该就是最让人无法忍受的地方了。
     简单归简单,简单到无脑的设计。缺陷也很致命:

  • 随着功能的增加而增加表示权限的字段,DBA看见估计已经哭的不成人样了。
  • 每个管理员对于增删改查等操作根本无法做出细化的权限分配。
      对于这个加字段的方法,我想可以用一个字段,里面存放JSON数据字符串而表示,这样在存取的时候多一步解析,看起来“完美”的解决了这个随着模块的增加而加字段的问题。麻烦归麻烦点,总体还能正常工作。毕竟是权限要求细化程度不高的小站。而哪一天BOSS说给我把谁谁变成哪个组,要哪些管理权限,只能看,不能增加不能删除。好吧,还好,涉及用户不多,我在网页上多做判断好了,把增加和删除不显示出来。看起来我又挺过去了。
     但这总归不是办法,我明白了这个权限表设计的只能算是失败的。
     怎么样的设计才是完美的呢?
     回到需求上来,几个模块,几个组,一批用户。
     权限针对的管理对象是模块,而一个模块最少需要四种管理手段,即传统的增删改查。一个组拥有这个模块的所有仅限,另一个组只拥有该模块的查看浏览权限。如何设计?
     好在我找到了比较合适的方法。权限表的设计由模块做为对象。
     组ID,模块ID,ADD,MODI,DEL等几个主要字段,0和1区分是否有管理权限。用户只要指定组,就获取了某一种管理权限。这样的设计在后期增加模块的情况下只需要为某个组增加几个数据记录而已,为组ID做个索引,还是有速度优化空间的。而更大的好处就是权限被细化了。看起来很完美的解决方案。
     只是看起来。
     如果哪天为了增加个临时体验帐号。如何是好?如果哪天组被删除掉了,如何是好?
     我擦,组都没了,我的用户都没权限了。
     失败了?显然是的。
     简单的改动一下,把组ID换成USER_ID,好了,组没了就没了吧。把组又细化到人身上,人对于模块拥有哪些权限,有五个模块就会出现关于这个USER_ID的五条记录,一个矩阵。说回来,这个组怎么办?
     组只是一个抽象的概念,如果在网页上表示这么个矩阵:
     模块一:checkbox, checkbox, checkbox
     模块二:checkbox, checkbox, checkbox
     模块三:checkbox, checkbox, checkbox
     模块四:checkbox, checkbox, checkbox
     对于组的权限只是一个简单的JS效果,把某些CHECKBOX搞成选中状态就OK了。这样可以做到非常人性化,每个模块的权限可以加上两个日期,起始日期,结束日期,临时VIP就出来了,月会员制。
     勾选了组,自动选中一些CHECKBOX,我再把CHECKBOX全点掉,这货属于管理员组,但没有一点权限。谁说同一个组的人权限必须相同呢?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值