权限系统设计思考

权限系统，很重要，对软件业务有着基础又是核心的作用，第一次设计了权限系统并开发实现，这中间有些东西还是值得去回忆跟思考的。

权限本身其实也是数据库里面的数据，一条记录，通过编写程序，让数据库记录成为控制访问与操作的权限，是权限设计最本质的东西，开发完了，我才发现。

权限系统本身的复杂性，灵活性，可以根据各个不同的公司规模，软件使用规模，项目范围等等来设计。所以在网上找到的那些关于权限的资料，不可能有相同的思想。

设计这些经典权限系统结构的高人，给我们留下宝贵的财富，参考这些设计，可以设计出自己想要的权限系统。这些正是我们的积累。

权限系统最根本的部分就是控制菜单与用户权限，

权限系统中的权限是对页面的访问及操作的权限，而这些权限集中到一个集合中，我们可以称之为角色，这就是觉得意思。

现在许多权限系统的设计都是RBAC，也就是：基于角色的权限访问控制。

我看看这中间可能关系的数据库表的设计：

操作定义：tabOperate：id，operateName....

菜单定义：tabMenu：rootMenu，parentMent，menu，url....

菜单的操作：tabMenuOperate：id，operateId，menuId....

tabMenuOperate该表为最重要的，也是最原始的权限记录表，表的设计可以根据需要而设计，一条记录为一个权限，或者全部权限都记录在一条记录中（我使用的是前者）

角色方面：

tabRole：id，roleName....

tabRolePower：id，roleId，menuOperateId....

根据RBAC的设计，角色为权限的集合，那么tabRole与tabMenuOperate之间存在多对多的设计，也应对着不同角色拥有多个权限，

用户方面：

tabUser：id，userCode....

tabUserRole：id，userId，roleId....

tabUser与tabRole为多对多的关系，一个用户可以拥有多个角色，也就是拥有多个权限集合。

这样以后我们就可以完全通过角色的授权于回收权限来控制角色的权限以达到对用户权限的收放。所有操作都是通过角色来完全，但是这样不灵活，为什么，权限没有直接控制到用户，但我们要单独为一个用户受权时，我们必须先创建一个角色。这是比较麻烦的，如果这样的情况多了，角色会非常多。

那么可以增加用户直接授权的设计：

用户权限表：tabUserOperate：id，ruserId，menuOperateId....

用户直接与权限表对应，这中间是多对多的关系，用户就可以拥有多个直接授权。

回想一下，设个设计比较简单，在UI上的操作上就需要发挥想象，设计操作上简单。

然后我们会发现，这中间都使用id进行关联，因为id稳定，不管是name还是code都是可变得，很难控制。

权限系统设计为同之后，可以再多个项目上使用，这样就很大程度提高了软件的开发效率了。