您好，我是湘王，这是我的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查询的，这一点多插一句嘴。
感谢您的大驾光临！咨询技术、产品、运营和管理相关问题，请关注后留言。欢迎骚扰，不胜荣幸～
没有了爱的语言，所有的文字都是乏味的
