动态菜单/RBAC标准完整权限管理系统的实现,通用角色权限控制系统五张表逻辑关联设计实现_权限设计五张表

序言：

众所周知，RBAC（Role-Based Access Control，基于角色的访问控制）权限系统是每个系统里面必备的最基本的系统，然而权限系统设计有时挺麻烦的，现在整理了下，给正在开发此模块的朋友一个思路！

　　设计基础：用户、角色、权限三大核心表，加上用户角色、角色权限两个映射表(用于给用户表关联上权限表)。这样就可以通过登录的用户来获取权限列表，或判断是否拥有某个权限。

　　大致用到５张表：用户表（s_user）、角色表（s_role）、菜单表（s_menu）、用户角色表（s_user_role）、角色菜单表（s_role_menu）<注：表前加前缀s代表这些是系统表，表名划分业务范畴,mysql中命名尽量全部采用小写，mysql在windows下是不区分大小写的，但是在linux下严格区分的，而且java或者mybatis这些持久层操作都是严格区分大小写的，为了不至于混乱。建议全小写或全大写，如果是sql server则建议驼峰命名方式比如:s_UserRole（我个人也比较喜欢这种）>。

各表的大体表结构如下：

• 　　１、用户表（s_user）：user_id,user_name、pwd,state,user_type
• 　　２、角色表（s_role）：role_id,role_name,description
• 　　３、菜单表（s_menu）：menu_id,menu_pid,sort,menu_name,func_name,is_enabled,description
• 　　４、用户角色表（s_user_role）：urid、user_id、role_id
• 　　５、角色菜单表（s_role_menu）：rmid、role_id、menu_id

任何权限的需求，都是为广义的用户分配角色，角色拥有广义的权限。角色是最重要的中枢，隐藏做幕后黑手，从不出现在业务代码里，用行话说就是解除了用户和权限的直接耦合。

角色把用户群体抽象化，几百个用户变成几个特殊定义的角色，用户->角色->权限写成通用判断权限的方法：currUser.IsHave(xx权限)。核心就是一个sql联表查询语句，查询条件为用户id。

例如：
部门权限：部门也是一种角色，建立 部门表、部门角色表。通用权限方法里加上 当前部门->部门所属角色->权限