用户与权限管理数据库架构设计咨询及优化建议

核心表结构 #

1. 基础配置表 #

层级表 levels

用来实现层级嵌套结构（比如公司职级、部门层级）：

• level_id (主键): 层级唯一标识
• level_name: 层级名称（如“总部”、“区域分部”）
• parent_level_id (外键): 父层级ID，顶级层级设为NULL，支持无限嵌套
• description: 层级说明

角色表 roles

存储职位/角色信息，关联到对应层级：

• role_id (主键): 角色唯一标识
• role_name: 角色名称（如“部门经理”、“普通员工”）
• level_id (外键): 所属层级ID，满足“每个层级包含多个角色”的要求
• description: 角色职责说明

权限表 permissions

拆分细粒度权限项，覆盖组操作的所有场景：

• permission_id (主键): 权限唯一标识
• permission_code: 权限编码（如GROUP_CRUD_OWN、GROUP_VIEW_OTHER、GROUP_EDIT_OTHER）
• permission_name: 权限名称（如“所属组全量CRUD”、“查看非所属组”、“编辑非所属组”）
• module: 权限所属模块（如“组管理”）

2. 用户相关表 #

用户表 users

明确绑定唯一层级和组，解决你关于用户-组关系的疑问：

• user_id (主键): 用户唯一标识
• username: 登录账号
• real_name: 真实姓名
• level_id (外键): 所属层级ID（多对一，一个用户仅属一个层级）
• group_id (外键): 所属组ID（多对一，完全符合“每个用户仅归属一个组”的规则）
• status: 用户状态（启用/禁用）

用户-角色关联表 user_roles

实现用户多角色的需求（多对多）：

• user_role_id (主键): 关联记录ID
• user_id (外键): 用户ID
• role_id (外键): 角色ID
• grant_time: 角色授予时间

角色-权限关联表 role_permissions

实现角色绑定多权限的需求（多对多）：

• role_permission_id (主键): 关联记录ID
• role_id (外键): 角色ID
• permission_id (外键): 权限ID

3. 组表 groups #

存储团队信息，关联到对应层级：

• group_id (主键): 组唯一标识
• group_name: 组名称（如“产品部一组”）
• level_id (外键): 所属层级ID
• leader_id (外键): 组负责人（关联users表）
• description: 组说明

4. 特殊权限补充表 #

针对“部分用户可编辑非所属组”的灵活需求，新增user_group_permissions表：

• user_group_perm_id (主键): 关联记录ID
• user_id (外键): 用户ID
• group_id (外键): 目标非所属组ID
• permission_id (外键): 授予的权限（如GROUP_EDIT_OTHER）
• grant_time: 权限授予时间

关键逻辑说明 #

1. 用户与组的关系：必须设为多对一，因为你的规则明确要求每个用户仅归属一个组，多个用户可以属于同一个组，完全匹配需求。
2. 所属组CRUD权限：可以通过两种方式实现：
   • 给所有用户默认授予GROUP_CRUD_OWN权限（初始化用户时自动绑定）
   • 给基础角色绑定该权限，所有用户至少拥有一个基础角色
3. 非所属组权限：
   • 所有用户默认拥有GROUP_VIEW_OTHER权限（全局默认权限或基础角色包含）
   • 需要编辑非所属组的用户，要么给其角色绑定GROUP_EDIT_OTHER权限，要么通过user_group_permissions表单独指定某用户对某非所属组的编辑权限，两种方式按需选择
4. 层级结构支撑：levels表通过parent_level_id实现嵌套，角色、用户、组都关联到层级，满足“每个层级包含多个角色和用户”的要求。

内容的提问来源于stack exchange，提问作者Menna Magdy