在关系型数据库中储存树形结构

adjacency list

邻接表显然是最简单的方式，也是在实践中经常用到的。其储存节点以及直接父节点来进行储存树形结构

邻接表结构简单，查询修改节点的直接父节点都很容易。然而如果返回父节点下的所有节点之类的跨层操作那就很麻烦了，需要频繁进行递归。

因此邻接表比较适合层次简单，或者基本只对直接父子节点进行操作的场景

id	name	parent_id
1	computer	0
2	apple	1
3	rog	1
4	mac air m2	2

path enumeration

储存根节点到本节点完整路径。

新增修改都比较容易，直接增加修改路径即可。对于查询就相对比较麻烦了，需要通过like之类的，并且完整路径很有可能会超出索引的最佳长度，对查询性能有损耗

在实践中常常与邻接表一起结合使用

id	name	parent_id
1	computer	0
2	apple	1
3	rog	1
4	mac air m2	2

nested set

嵌套集合模型是根据遍历树对节点进行编号，遍历树对每个节点进行两次访问，按访问的顺序分配编号，并且在两次访问时都进行编号。这给每个节点留下了两个数字，存储为两个属性。查询变得不昂贵:可以通过比较这些数字来测试层次成员关系。更新需要重新编号，因此代价很高。使用有理数而不是整数的细化可以避免重新编号，因此更新速度更快，尽管要复杂得多

left是前序遍历的第一次访问，right则是第二次访问。比如对于下表中的mac air m2是第3步时发生了第一次访问，同时由于是最左子节点，因此会发生返回，那么第4步发生了第二次访问。

id	name	left	right
1	computer	1	8
2	apple	2	5
3	rog	6	7
4	mac air m2	3	4

wiki中有一个很好的图展示了left、right的计算

nested set方法查询删除所有子节点非常快，然而模型较为复杂，插入移动极为麻烦，需要重建left、right。

因此，nested set更适用于层次比较复杂，查询远远大于插入删除修改的情况

在支持recursive common table expression的关系型数据库中，即使是递归查询也得到了很好的改善，Mysql也在8.0引入了该特性。因此相比于nested set，邻接表应该是首选

closure table

储存节点之间的关系，指明两节点之间的父子关系以及深度

parent	child	depth
1	2	1
1	3	1
2	4	1
1	4	2

在closure table中还会指明每个节点都是自己深度为0的父节点，在上表中被省略了

closure table方案在查询树形结构任意层级关系效率都很高，但相比于其他方案占用了更多空间，新增修改也较为麻烦

Ref

1. https://en.wikipedia.org/wiki/Nested_set_model
2. https://www.waitingforcode.com/mysql/managing-hierarchical-data-in-mysql-path-enumeration/read
3. https://fueled.com/the-cache/posts/backend/closure-table/
4. https://dev.mysql.com/doc/refman/8.0/en/with.html