用户、角色、权限为什么要拆成五张表比较好？换做你会如何设计？

目录

一. 用户，角色，权限

二. 权限系统实现的两种方案

2.1 用户+权限实现权限系统

2.2 用户+角色+权限实现权限系统

一. 用户，角色，权限

用户：很简单的一个词，你做出来一个产品，或者一个网站，任何人使用你的产品，他都可以理解为是你产品的用户。

角色：角色是用户更高一层的抽象。刚才我们说到了，所有人都是用户，但在众多用户中，还可以对他们进行细粒度的划分，例如对大多数人都只是普通的用户，有少部分不仅是用户还具备管理员身份。这只是简单的划分，例如一个复杂的系统网上购物系统中，有普通用户，有VIP高级用户，有超级管理员，有货物供应商，在平台上充当着不同的角色，不同的角色通常也对应着不同的权限。

权限：上面提到了角色，我们自然可以想到，角色不同，拥有的权限也不尽相同，不可能给所有角色相同的权限。通常来说，普通用户角色通常只有查看的权利，没有增删改的权利，而管理员角色通常具备增删改的权限；这就是不同角色对应权限最直观的体现。

用户和角色多对多关系：一个管理员，他既有用户的角色身份，又有管理员的角色身份；反之，管理员也不一定只对应一个用户，多个用户都可以是管理员。

角色和权限多对多关系：一个管理员，他既有普通用户的权限，又有普通用户没有的管理员权限；反之，多个人都可以拥有同一个相同的权限。

二. 权限系统实现的两种方案

2.1 用户+权限实现权限系统

在有些小的项目中，比如大学计算机项目课程设计，通常会发现关于用户权限的设计非常简单，通常都是设计一个权限表列出各种权限，然后就是用户表，用户表中设计一个权限字段关联权限表的主键，从而达到设计用户权限的目的。

这种实现权限的方式优点就是非常简单，只需要两张表就可以完成，程序代码也非常简单，难度较低；

缺点就是用户操作不便，权限关系比较乱，当然这只是相对而言，我们一会拿它和方案二来做对比；

2.2 用户+角色+权限实现权限系统

这种方式是比较广泛使用的权限设计系统，它需要设计五张表，分别是

t1：用户表：存储当前系统所有用户信息；

t2：角色表：角色表创建后表数据通常相对固定，就是几种不同的角色，只在后续项目维护期间新增少量新的角色；

t3：权限表；权限表创建后数据通常也相对固定，通常存储菜单页的操作权限，只在后续项目新增菜单期间或许需要新增权限菜单数据；

t4：角色和权限关联表；记录不同角色对应的操作权限，比如角色A允许操作菜单a、b；角色B允许操作菜单b、c，

t5：用户和角色关联表：记录系统用户对应的角色，可以存储多条。举例，管理员用户对应 Manager 角色，也对应 User 角色，可以对应两条数据，也可以权限高的角色 Manager 存储，只对应一条数据；

但小编认为只存一条不太合理，还是存多条比较合理。因为一个用户可能对应多个角色，每个角色的各自权限可能存在交叉，比如角色A允许操作菜单a、b；角色B允许操作菜单b、c，此时如果只存储一条关联数据，无法存储，除非你的项目在设计之初，角色权限存在层级关系，即角色a是低等级角色，允许操作菜单a、b；角色B比角色A等级高，不仅包含菜单a、b，还有菜单c；此时只存储角色B一条数据可以覆盖到三个菜单操作权限，否则必须存储多条关联关系，在程序代码层面将关联关系存储为List<用户和角色关联表>，然后进行权限的合并去重。

第二种方案要比第一种方案在编码层面更复杂，需要用到5张表，并需要用到多表查询，但是却非常利于系统对各个用户的权限控制，加入角色表我们可以将所有的用户划分为不同的角色，让权限关系更加清晰，当我们需要添加新的用户时，只需要让他与角色表相关联，然后就可以通过角色与权限关联表确认当前用户都具有哪些权限，程序的健壮性和可扩展性更强。