用户权限菜单的DB实现

用户权限菜单的DB实现

用户权限菜单

工作中经常会涉及到为一个系统设计一个用户权限管理的功能。虽然，这个是很好理解，就是每个角色都有特定的权限，查看特定的菜单。一方面是为了工作的职责的区分，另一方面也是为了避免“误操作”带来的风险。

通过以下步骤，思考如何实现一个用户的权限管理：

• 目的是什么？

最终的目的是什么？首先要思考清楚这个，才能定好一个总的方向，对计划进行校准。

目的是为了区分不同用户之间的权限，从而配置不同的菜单选项。这样，既可以简化用户菜单，提高使用时的检索效率，也可以让用户把更多的注意力放在自己的职责上。

• 区分不同用户的标准是什么？

既然要为不同的用户做不同的区分，那就必须要有一个标准，这个标准将会是用户的区分，也是权限的区分。

这里提两种区分的标准：全局、定制。

全局就是这一个标准适用于所有的系统用户，通过这个标准对全部用户进行划分，不同类型的用户对应不同的权限，同一类型的用户拥有统一的菜单。这个方法就比较简单，也比较通用。一般可以分为：一级、二级、三级 或者 管理者、分系统管理者、末端用户 等各种形式。这个比较难的点在于对现有管理架构的职责分析，得到一个比较合理的标准。

定制就是针对每一个不同的用户，配置它独有的权限，可以提供权限的拓展和收缩。这个相对于全局，可以少去一部分通用规则的思考，但是需要增加对不同模块的细致区分，便于用户权限的拓展。

对于上面两种，全局一般可以单独进行使用，并且可以得到不错的效果；定制则很少单独进行应用，它更多的是通过搭配简单的全局分类来实现更细腻的权限管理，比如：通过全局划分为管理者、模块管理者、末端用户三种，管理者为模块管理者授权、模块管理者为末端用户发放权限。这样可以实现更灵活的权限管理框架。

• 如何设计表？

设计表的原则其实有比较好的规范，这个大家可以参考相关资料去了解。我想说的是，不同的环境对于表的设计是有不同的要求的，不用刻意去拟合既定的规范。

设计表的时候，我个人比较倾向于实体和关系的区分，实体、不同实体见的关联关系通过一个表去进行表示，这样对应到实际开发中也比较好管理。

这样，大概可以罗列出以下几个表：

用户信息：这个表存放用户的相关信息，包括：用户id、昵称、密码、邮箱、角色id 等。这个表存放的信息是用户的基本信息。简化考虑可以是用户注册信息的对应。

角色信息：这个表存放的信息是关于对用户群体划分的标准，包括：角色id，名称

资源信息：这个表存放的是所有的资源信息。资源，即所有的请求地址。包括前端跳转路径，后端提供的所有接口路径

关系信息：这个表用于描述角色信息和资源信息之间的关系，存放的信息包括：角色id、资源id

如果使用的是定制+全局的模式：

角色资源关系表：用于描述角色和资源之间的关系

用户资源关系表：用于描述用户和资源之间的关系

• 如何呈现最终的结果？

有了以上几个表格，我们就可以开始搭建我们的最终模型了。

我们的最终目标有这么几个要求：有最高权限管理人员、有分系统管理人员、有普通员工、运维人员；用户的角色不能选择，只能由上一级账户授权；不同用户可以拥有不同的菜单权限。

项目搭建之后，设计、整理表信息，运维人员负责数据库的直接操作，创建所需要的表；系统首次开启，默认提供admin账户，开启授权菜单，且只能使用一次，为其他账户授权之后自动注销；创建用户，通过admin授权最高权限管理员角色，开启对应菜单，这个菜单是通过角色资源菜单进行配置的；创建普通用户，通过 最高权限管理人员的授权，得到分系统人员权限管理资格，开启对应菜单（通过角色资源关系表查询）；创建普通用户，由对应系统管理者进行授权，保存在用户资源关系表中；创建普通用户，由最高权限管理员授权资源表操作权限，维护资源表信息；

这样就基本上实现了权限的基本控制，这个只是我个人的一些想法，并不是最优的解决方案。如果你有更好的想法可以告诉我，相互讨论，共同成长。