web权限管理设计（1）——设计的要点分析（4）

上篇中描述了角色id的一些基本的要求：

1. 角色id一定大于被他继承的角色，也一定小于继承他的角色
2. 角色的id：最底层从0开始，最高层从21亿开始。每层一万个位置，所以共计有21万层
3. 层次越高的角色，id值越大
4. 每次在一个新的层次增加角色，其id位于其继承者和被继承者的中间那一层。

上面的结论在实际应用中，会有一点问题，因为权限由人设计，人的认识不可能那么完美，免不了后期需要修改。所以，角色之间的继承关系，免不了会变动，包括位于最底层的角色，说不定以后也会继承自其他角色。然后它已经位于最底层，没有空间给他拓展了。这是不行的。

这篇文章的目的，就是设计更灵活的角色id，减少人的设计失误导致权限模型的奔溃。

结论再次深入分析

我仔细想了想，结论还需要增加两点：

5. 同一层次的角色不存在继承关系
6. 角色id是动态可变的，且可以人为指定

第一点是绝对的原则，就没什么好分析。
第二点是基础，也没什么好分析了

第三、四、五点

第三点的含义，本身很好理解，高层次的角色id取值范围本来就比低层次的高嘛。

主要还想讲讲层次的一些理解。

最开始，我想的是，角色一定有其自己的含义，所以，根据其实际的意义，将关联的一组聚到同一层。这样以后生成图结构时看起来才合理。

但是，上述想法依赖管理者的设计能力，如果管理者能力不行，会导致权限系统很烂。毕竟，计算机可不能理解角色的实际意义的。

所以，我放弃了通过实际意义去安排层次的想法，而是用固定的规律，让程序去保证角色的id关系：

1. 最底层依然是没有继承任何角色的
2. 角色的层次可以变化
3. 同一层的角色不会存在继承关系

第一点是规定，好理解，对于第二点和第三点，有必要解释一下。

首先，看个例子：
角色H，J没有继承自其他角色，所以他们在最底层：

然后，再举个例子：

增加角色O和角色P，角色O继承自角色H，角色P继承自角色J，他们的关系如下图，那么他们的id该如何计算？

根据第四点，O和P是新层次，所以id通过继承者和被继承者计算得到，但是他们没有父节点呀？其实他们有，隐藏的管理员就是，所以他们的id就是通过最底层和管理员层计算得到的中间层，通过中间值法，这在上一篇已经讲过。这里不再重复。

再举个例子：
现在需要增加一个角色A，它没有继承关系，而角色J改为继承角色A，所以他们的关系就变成下图：

可以发现，角色A和角色H并排了，J提升了一个档次，而O和P不变。

因为角色A没有继承，所以它应该在最底层，所以需要在最底层给他安排一个id。

但是角色J本来在最底层待着，由于它的继承关系发生了变化，所以得给他提升一下档次了。那么角色J该提升到哪呢？因为它的继承者和被继承者都是明确的，所以就按照中间值法，在角色P和角色A的中间，找中间层给它安排位置。

所以程序里应该这么个流程:

1. 新增角色A，由于它没有继承关系，所以它应该位于最底层
2. 此时修改角色J的继承关系需要发生变化，所以就修改角色J的id，计算方法如上说明

这也印证了第五点，因为同一层一旦出现继承关系，该角色就会重新计算id

再再举一个例子：

我又增加了一个角色K，它继承自角色J，那么它的id怎么计算，角色K没有明确的父节点，是不是该去找管理员呢？

然而，在找管理员之前，因为角色J还有个继承者角色P，既然大家都继承自同一层，为什么不能待在同一层呢？
所以，在拿管理员做判断前，还需要去查一下有没有“同行”，如果有的话，就不必麻烦管理员了，直接共享同一层就好了

再再再举一个例子：
新增一个角色R，它继承自角色P，按照上面的方法，它应该找管理员层计算id。

现在我再增加一个角色Z，继承自角色K，那么角色Z也该找管理员吗？它不行，因为角色K的兄弟角色P有父节点，那么角色Z就该找角色K的父节点做兄弟。所以角色Z就直接去找角色P共享同一层就好了：

所以可以得出规律：

1. 当角色继承关系改变时，只需要变化的是该角色，不会影响到其他角色。当然，角色组还是会受影响的
2. 在没有明确的父节点时，管理员层作为隐藏的父节点
3. 如果没有明确的父节点，而继承的节点还有别的父节点，那么直接与该父节点共享一层
4. 如果没有明确的父节点，而继承的节点的兄弟节点还有别的父节点，那么直接与该继承者共享一层

这里再补充第一点的角色组是如何受影响的：
如果角色组与角色的关系是间接继承，那么，角色id的变化，不会影响到角色组，只有直接继承才会影响，这个好办：

select * from 角色组表 where 角色 like '%,id,%'

语句上大概那么个意思，反正就是可以搜索到包含该角色的角色组，然后将对应的id改掉就可以了。

第六点

角色id可变在上面已经体现了。而允许人为指定id，最主要是因为刚开始给权限模型打基础时，让角色id不至于跨度太大。

如下图：

H作为最底层角色，自然会安排好角色id，但是当再添加角色O时，由于最开始还没准备好更高层的角色，导致没有角色继承自角色O，那么如果交由程序去计算的话，角色O的id就会去找管理员层计算。

而管理者明明知道角色O就是个靠近底层的角色。没必要安排那么高的层次。否则以后H和O之间的空间大概率用不上，很浪费。所以需要有人为指定id的功能。

当然，还有一个作用：就是当某天发现权限设计真的出问题了，还可以人为修改角色id，不至于去数据库里修改。