您好,我是湘王,这是我的博客园,欢迎您来,欢迎您再来~
RBAC类型的权限,本质上是一种对资源访问路径的控制,且具有典型的树型层次结构。而树型结构,天然地就有父结点和子结点的关系以及区别。就像前面展示过的业务系统的树型结构:
从我个人的开发经验来看,在大多数情况下,数据库的权限表可以这样设计:
这也算是抛砖引玉吧。
和普通的表结构一样,将主键设为自增编码。这种方式的优点是便于操作和实现。
缺点是在设计数据库表结构时不便于观察各节点之间的联系,因此就出现了一种能够让主键携带更多信息的编码方式:
其实我们每个人的身份证的前六位就是一种最常见的「占位符」编码,例如「420」开头的身份证就都是湖北省的。
利用编码中的占位符来代替单纯的数字这么做的底层逻辑是:
1、所有层级为「1」的大类按照自然数的编码顺序依次递增
2、所有编码,都从「1」开始计数,如1、1010000、1010100、2010000
3、从层级为2的权限开始,编码为7位数,例如:1010000
4、编码第一位(1):占位符,表示业务编号,与大类的业务编码对应,每个占位符都可能有99个直接子类
5、编码第二、三位(01):表示层级为3的儿子权限,从01~99,可以有99个儿子
6、编码第四、五位(00):表示层级为4的孙子权限,从01~99,可以有99个孙子
7、编码第六、七位(00):表示层级为5的曾孙权限,从01~99,可以有99个曾孙
这种编号方式能很清晰地看出层级结构,但如果需要无限扩展层级结构时就无能为力。自增方式可以很方便地实现无限扩展,但编号却毫无规律,不容易看出层级关联。
所以,如果层级不多,建议使用占位符方式,反之利用自增方式。一般来说权限数据相对比较固定,极少改动,因此可以使用MyISAM的存储引擎,且事先可以以初始化的方式创建较为完整的权限数据。
从上面的过程可以看出来,权限设计其实是一件比较抽象的思考活动。有时候一些复杂的权限、角色、组织、用户等内容交织在一起,会让人觉得无从下手。其实只要通过适当的方法来解构,就可以更好地理解了。例如:“汉堡包”法。
顾名思义,就是能像汉堡包那样直观、清晰地了解权限系统所包括的内容。
“汉堡包”上层的组织结构可能是这样的:
“汉堡包”下层的权限集合则可能是这样的:
而汉堡包中间的分组&角色则可能又是这样的:
如果要搞权限叠加的话,嗯~~~,是这样的:
这里把和权限进行连线的图省略掉了,因为实在是太~过~复~杂~了~~,完全不是人看的玩意。
所以呢,对于刚开始接触权限系统的初学者,也不要被吓到了,完全可以通过这种方式进行思维训练,来一步步熟悉:
1、先明确委托方的组织架构图,设计出上层汉堡包
2、再依据业务需求细化出系统的功能权限,设计出下层汉堡包
3、结合业务要求,再在中间填充各类角色及分组
4、最后将它们用线条关联起来
5、熟练以后,就不用再在纸上或者绘图软件中画出来
6、只需在脑子里就可以勾勒出来整个权限系统的轮廓了
可能有些同学会有一个疑问:为什么在parentids字段中的值,结尾都要加个「,」?
答案就在执行SQL时。
例如,查找id=1的所有子类
有「,」:SELECT * FROM sys_permission WHERE parentids LIKE '%1,%'
无「,」:SELECT * FROM sys_permission WHERE parentids LIKE '%1%'
可以比较一下查询结果会有什么不同。
当然,互联网的业务的MySQL中是不允许出现LIKE查询的,这一点多插一句嘴。
感谢您的大驾光临!咨询技术、产品、运营和管理相关问题,请关注后留言。欢迎骚扰,不胜荣幸~
标签:编码,层级,自定义,汉堡包,占位,RBAC,99,权限 From: https://www.cnblogs.com/xiangwang1111/p/16967464.html