上回说到
需求：机构信息 - 左侧添加组织架构，按系统-父机构-子机构-部门-用户显示
从需求可以看出返回的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查询到对应的系统信息，即系统信息只有顶级父节点才有查询角色表，找到对应的系统Name
select 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，但这并不妨碍我们解决问题
上述证明我们设想的层级结构其实是有一点问题的，进行修改后，我们的层级结构终于出现了
(累の不行，真事 注:真事=真的是这样)
系统{
系统信息
机构{
机构信息
部门信息{
员工信息
员工信息
...
}
部门信息{
员工信息
员工信息
...
}
...
子机构{
...
}
}
}细节处理
部门和员工之间的关系可以通过Map进行关系处理
先根据机构名称，查询所有的对应的user
select * from t_ims_auth_user where inst_name ="白虎队";
遍历用户，写入Map，Key为部门名称 Value为user信息
List<User> list = ...
Map<String,object> map = ...
for(User user:list){
//如部门name无,写入暂无
if(){
}
map.put(user.getDeptName,user)
}
这样我们整个业务流程就算是捋清了
