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
- https://en.wikipedia.org/wiki/Nested_set_model
- https://www.waitingforcode.com/mysql/managing-hierarchical-data-in-mysql-path-enumeration/read
- https://fueled.com/the-cache/posts/backend/closure-table/
- https://dev.mysql.com/doc/refman/8.0/en/with.html
