怎么将一棵树保存到数据库中去

　假设有如下一棵树：

要存储于数据库中，最简单直接的方法，就是存储每个元素的父节点ID。

暂且把这种方法命名依赖父节点法，因此表结构设计如下：

存储的数据如下格式：

这种结构下，如果查询某一个节点的直接子节点，十分容易，比如要查询D节点的子节点。

文中使用公司部门结构树作为栗子，要在mysql中存储这个公司部门结构树

邻接表想必大家都不陌生吧，用邻接表的关键是，在每个节点存储他的父节点的id。

在每一个部门信息中都存储了他的父节点id，parent_id字段

导入数据的过程就不说了，直接来看下数据吧：

这里使用常用的几种查询方式来看下这种方案的查询

可以通过parent_id做查询条件，可以快速查询到一个部门的直属下级部门

通过部门信息中的parent_id去查相应的父节点信息就可以快速实现

这种数据存储结构下，更新数据是比较方便快捷的，添加数据时直接找准父节点的id，组织部门变更时，也直接变更父id就好了，删除时候，看自己业务是否需要删除子节点这几种情况，

路径标的要点，就是每个节点存储根节点到该节点的路径，其实我觉得和别的几种方案可以共用

在每一个部门信息中都存储了他完整的路径，path字段

导入数据的过程就不说了，直接来看下数据吧：

使用路径表，通过path这个字段查询起来是比较困难的，一般都需要使用like，CONCAT函数、REPLACE函数等做字符串的处理逻辑，查询起来比较复杂，这里不做展示了，线上服务不建议使用这种方式，查询效率低会影响到服务性能，一般建议和邻接表方式统一使用，同时添加parent_id和path字段，parent_id用来查询，path用来查看节点完整的路径

这种数据存储结构下，更新数据是比较方便快捷的，添加数据时直接找准路径就好，组织部门变更时，也直接找准路径就好，删除时候，看自己业务是否需要删除子节点这几种情况，

Closure Table，百度直译过来叫闭合表，大多数人叫做闭包表，这种方案的要点是存储公司部门信息主表中，不存储节点关系的数据，使用另一张关系表来存储节点之间的关系，其中包含了任何两个有关系（上下级）节点的关联信息

公司部门信息主表，只需要存储部门的本身信息

主要包括三个字段

要点就是关系表的一条记录是一个上级节点、下级节点、与他们之间的路径距离。拿部门结构图来举例子

总公司-企划部的关系数据是：

总公司-大区A的关系数据是：

关系表中存储所有的节点路径信息，还用distance表示路径的距离，需要把树形结构中每两个节点之间的路径信息都维护进来。

数据存储的过程就拿导入总公司-门店A的过程做个示例。主表的数据存储就不说，说下关系中，存储部门结构的路径信息，总公司-门店A总共包含以下几条路径：

看到了么，是存储了所有总公司-门店A之间的路径信息

这里使用常用的几种查询方式来看下这种方案的查询

这种数据存储结构下，更新数据比较麻烦，因为他存储了两节点直接所有路径信息（包括中间节点的）

---