请教下后台管理用户分类怎么写比较好?

需求描述

各位社友,请教一个问题。最近有个需求写个后台管理,大致分三级。

  • 首先一级总的,二级代理,三级分公司,三级分公司有多个归属于二级代理,单个用户是归属到三级分公司下面的。
  • 一级总账号,可以看所有的用户信息
  • 二分代理账号,可以看到自己下面所有三级的公司用户信息或单个分公司信息
  • 没有三级公司账号需求

问题描述

假设,目前有个简单的getUserList通用接口,那一级或二级的账号要看对应的用户列表,是要通过一级或者二级的级别id和绑定的公司id集合,去whereIn筛选,因为也有可能有需要单独看某个公司用户列表的需求,这是我能想到的。但是感觉遇到类似的这种条件筛选接口,那我需要每个接口都要加whereIn条件,我感觉这种方式比较不太好。

疑问帮助

所以想请问下,社友们,有没有什么比较好的解决方案来进行这种筛选方案,而不是每个接口中都要去添加whereIn。

《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
讨论数量: 8

方案一:

如你所说,用父子关系去定义,再用whereIn查询。树关系可以缓存

方案二:

人和公司关系可以往上级公司做同步就可以了。

2年前 评论
Swww18 (楼主) 2年前

如果不想使用 whereIn ,可以保存下二级代理和其三级分公司下用户之间的关系,冗余字段或是新增一个表

2年前 评论
Swww18 (楼主) 2年前

新建个关系表比较好,更灵活,扩展性更好。

表:relation

{
user_id,//当前用户id
user_level,//当前用户等级
ancestor_id,//祖先id
ancestor_level,//祖先等级
deep,//第几代,上级是1,上上级是2,以此类推。
}

从关系表筛选出符合条件的人的id,然后拿去用户表in查询。
$uid = 1000;

select user_id from relation  where ancestor_id = {$uid} and user_level = 3 and deep < 3;
2年前 评论
Swww18 (楼主) 2年前

如果后续方便查询,可以在用户表上面新增两个字段 一个父级id,一个顶级id,然后你只需要保证父级id是自己上级就行,刚做了一套三级代理的系统,这样确实查询很方便
比如要顶级要查看二级三级代理的订单等,当然用的 whereIn

2年前 评论

这个地方属于树桩结构的话题,正好我最近有在研究,直接分享出来(更深度的了解参考:《SQL 反模式》 第三节 简单的树):


一般比较普遍的就是四种方法:(具体见 SQL Anti-patterns这本书)

Adjacency List:每一条记录存parent_id

Path Enumerations:每一条记录存整个tree path经过的node枚举

Nested Sets:每一条记录存 nleft 和 nright

Closure Table:维护一个表,所有的tree path作为记录进行保存。

邻接表

邻接表是存储树形结构最普通的一种方案了,通过添加 parent_id 字段来确定树的父子关系。

递归查询

SQL Server 2005、Oracle 11、IBM DB2 和 PostgreSQL 8.4 这些数据库都支持递归查询,而 MySQL、SQLite 和 Infomix 是少数不支持的数据库。

如果递归查询语法被所有主流数据库所支持,那么使用邻接表的设计不会再有这么多限制了。

路径枚举

接表的问题之一是从树中获取一个给定节点的所有祖先开销很大。路径枚举的设计通过将所有的祖先信息联合成一个字符串,并保存为每个节点的一个属性,很巧妙的解决了这个问题。

path_comment 表中,我们使用 path 字段来代替原来的 parent_id 字段,将从这个结点开始到最顶级节点的所有 id 存储起来,就像文件目录一样。


根据你自己的业务选择合适的模式。你这里将来可能是无限递归(目前是三级,可能未来有多级?),可以优先考虑路径枚举;如果固定层级就是三级,衔邻表还是不错的选择。

2年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!