MERN应用用户角色权限体系MongoDB集合架构设计是否可行？

你当前的设计可以实现基础的权限控制逻辑，跑通业务流程没有问题，但存在多处数据冗余、关联逻辑混乱的问题，后续业务迭代、权限调整时很容易出现数据不一致的问题，维护成本会很高，不推荐直接使用。

• 数据重复冗余：USER_COLLECTION中已经存储了permissions数组，同时PERMISSIONS_COLLECTION又反向关联了用户ID和角色ID，ROLE_COLLECTION也关联了用户ID，三处都存储了权限/角色的关联关系，只要一处更新不同步就会导致权限判断错误。
• 角色表设计不合理：ROLE_COLLECTION的结构中每个角色文档只能绑定单个user_id，完全浪费了角色「一对多」的核心能力，同一个角色本来可以对应多个用户，按照现有设计每新增一个用户就要新增一条角色文档，完全没有必要。
• 权限关联逻辑冗余：同时做了用户直连权限、角色连权限、权限反向连用户和角色的多向绑定，后续排查单个用户的权限问题时需要核对三个集合的数据，排查成本极高。

针对MERN栈的MongoDB特性，兼顾查询效率和扩展性，推荐调整为以下单向关联的集合结构：

USER_COLLECTION（用户表） #

{
  user_id: 1,
  user_mail: "ss@mail.com",
  role_ids: [11] // 支持一个用户绑定多个角色，满足身兼数职的需求，单角色场景数组只存一个元素即可
}

ROLE_COLLECTION（角色表） #

{
  role_id: 11,
  role_name: "super_admin",
  permission_ids: [111, 112, 113, 114] // 一个角色绑定多个权限，调整角色权限只需要修改这个数组即可
}

PERMISSIONS_COLLECTION（权限表） #

{
  permission_id: 111,
  permission_name: "CREATE",
  permission_desc: "新增资源权限", // 可选字段，方便后台权限管理时做展示说明
  resource: "employee", // 可选字段，标记权限对应的业务资源，方便前端做页面粒度的权限控制
  action: "create_employee" // 可选字段，按钮级权限的标识，前端可直接判断是否渲染对应操作按钮
}

调整后的优势 #

• 无冗余数据：所有关联关系单向绑定，用户绑角色、角色绑权限，修改角色权限后所有对应用户的权限会自动同步，不会出现数据不一致的问题。
• 扩展性极强：后续新增角色、新增权限都只需要新增对应集合的文档即可，不需要修改原有结构；如果有特殊场景需要给单个用户单独加权限（不走通用角色），只需要在USER表新增extra_permission_ids字段单独存储即可，不影响原有逻辑。
• 查询效率高：用户登录后，只需要三次查询即可拿到全量权限：先查USER表拿到角色ID列表，再批量查ROLE表拿到所有权限ID列表，最后查PERMISSIONS表拿到完整权限内容，查询结果可以存在JWT或者Redis中，不需要每次接口请求都查库。

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