问题起源

最近接手的某款办公软件，其中要添加一些额外的功能，涉及到树状层级的部门，人员查找。又最近在学习若依管理系统，其中也设计到层级的部门管理，查看了其中的部门表设计与一些SQL编写，发掘有一些小小的差异，即可带来检索与查找的极大遍历。容我们慢慢道来。

若依中的dept表设计

若依系统中的sys_dept表设计字段如下：

若依系统中添加部门的操作页面如下：

我们选几个重点字段说一下：

1. parent_id字段：表明当前部门的上级部门节点id；
2. order_num：表明当前部门在其上级部门下的排序次序；
3. ancestors: 注释为“祖级列表”，我们来看一下表中的数据以及对应的真实的数据结构:

比如,若依中默认的部门级结构如下:

我们来看一下其中"若依科技->深圳总公司->研发部门"的数据库具体数据，尤其是ancestors数据是什么样的：

如图所示，研发部门的ancestors数据为“0,100,101”，0为所有部门父级，不表示具体部门，如果一个部门的父级只有0，表明其为最高级的部门；100表示dept_id=100的若依科技，101表示dept_id=101的深圳总公司。

乍一看这个字段设计的如此复杂，需要保存从最高级直到本级中的所有部门节点，给保存、更新带来了很大的复杂度，这样设计有什么好处呢？

另一种常用设计

说是另一种常用设计，更准确是说是我们当前系统的表设计，为了不违反公司相关规章，这里我就不贴真实的数据库表截图了，大概是这样的：

即仅通过一个parent_id来表明层级关系，这样带来的一个显而易见的好处便是保存与更新带来的操作比较简单。

差异

差异就在于若依中的层级表设计有字段来保存部门祖级的所有节点。最近实现业务代码涉及到这块儿功能才发觉其有很好的实用性。

列举所有子部门

层级结构中最常见的一个业务是列出部门下的所有子部门，那么应该如下编写代码呢？

显然，如果没有ancestors的帮助，我们需要在代码中通过parent_id逐层逐级的遍历列举以及合并列表，而有了ancestors帮助，我们只需要一行SQL语句：

.....WHERE dept_id IN ( SELECT dept_id FROM sys_dept WHERE find_in_set('100', ancestors ) )

逐级查找所有父级部门

这种业务通常处于低级部门规则覆盖高级部门规则的场景下，即部门人员总是采用部门层级最接近自己的部门的规章，按照这一原则来实现代码的话，ancestors直接列举出了从高到底各个层级部门，而仅有parent_id则需要通过代码来循环查找父级部门。