本文共 1508 字，大约阅读时间需要 5 分钟。
上回说到
需求：机构信息 - 左侧添加组织架构，按系统-父机构-子机构-部门-用户显示
从需求可以看出返回的Json对象必须是具有层级结构的，解决这个需求首先要思考的是返回Json的层级结构及包含关系
提出猜想
因为是层级的包含关系1、所有父机构所在的系统子机构必在其中
2、同理，子机构包含的部门，父机构必然包含因为，向上我们只需要找出顶级父辈的所在系统
向下我们只需找出底级子辈所在的部门这样思路就清晰了，我们只需要递归找出机构表，所有机构的层级结构即可
对应的返回层级：
系统{ 系统信息 顶级父辈机构{ 机构信息 ... 底级子辈机构{ 机构信息 部门{ 员工信息 } 部门{ 员工信息 } ... } } }
验证猜想
使用SQL递归查询数据(这个地方只是验证过程，后面并不需要使用递归SQL，无需担心)
id instid instCode instName parentId 1 1111 0001 白虎队 0 131 2222 0002 灰狼队 1111 132 3333 0003 青龙队 2222 164 4444 0004 赤蛇队 3333
查询机构角色表，找到机构对应的角色Id
instid role_id 1111 root 2222 null 3333 null 4444 null在这里就可以看出我们的第一个猜想是正确的，因为只有顶级父节点才有角色ID，
也就证明了其他子节点是无法通过角色ID查询到对应的系统信息，即系统信息只有顶级父节点才有 查询角色表，找到对应的系统Nameselect sys_name from role where role_id = "root";查询系统表，找到对应的系统信息
select * from t_ims_auth_sys where sys_name = "炒鸡特工队";
经过验证发现猜想1在数据库中的映射关系正是这样,而猜想2却在数据库中的映射关系和我们猜想的并不同，
这也证明了当有解决问题的想法出现时，一定要查询数据库验证，保证理论正确，才可以得出正确的操作步骤
那让我们来看一下猜想2哪里出错了
select * from t_ims_auth_user where inst_name ="白虎队";
经过查询数据库我们发现，使用机构名称查询用户表时，即使是顶级父辈也有对应的用户信息
(实际上经查询是每级都有用户信息和部门信息的)，即用户信息并不仅仅保留在底级子辈机构中
层级结构
OK，但这并不妨碍我们解决问题
上述证明我们设想的层级结构其实是有一点问题的，进行修改后，我们的层级结构终于出现了
(累の不行，真事 注:真事=真的是这样)系统{
系统信息 机构{ 机构信息 部门信息{ 员工信息 员工信息 ... } 部门信息{ 员工信息 员工信息 ... } ... 子机构{ ... } } }