自定义RBAC（3）

您好，我是湘王，这是我的51CTO博客，欢迎您来，欢迎您再来～

​

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查询的，这一点多插一句嘴。

​

​

感谢您的大驾光临！咨询技术、产品、运营和管理相关问题，请关注后留言。欢迎骚扰，不胜荣幸～

​