在 SQL 中管理层次结构：MPTT/嵌套集 vs 邻接列表 vs 存储路径

Question

一段时间以来，我一直在思考如何最好地处理 SQL 中的层次结构。由于邻接列表的局限性和 MPTT/嵌套集的复杂性，我开始考虑简单地将关键路径存储为简单的node_key/node_key/... 字符串。我决定整理一下这三种技术的优缺点：

创建/删除/移动节点所需的调用次数：

• 邻接 = 1
• MPTT = 3
• Path = 1（将旧节点路径替换为包含该路径的所有节点的新节点路径）

获取树所需的调用次数：

• 邻接 = [子级数]
• MPTT = 1
• 路径 = 1

获取节点/祖先路径所需的调用次数：

• 邻接 = [超层数]
• MPTT = 1
• 路径 = 0

获取子节点数所需的调用次数：

• 邻接 = [子级数]
• MPTT = 0（可以从右/左值计算）
• 路径 = 1

获取节点深度所需的调用次数：

• 邻接 = [超层数]
• MPTT = 1
• 路径 = 0

需要的数据库字段：

• 邻接 = 1（父）
• MPTT = 3（父、右、左）
• 路径 = 1（路径）

结论

存储路径技术在除一个以外的每个用例中都使用与其他技术相同或更少的调用。通过这种分析，存储路径显然是赢家。更不用说，它实现起来要简单得多，易于阅读等。

所以问题是，存储路径不应该被视为比 MPTT 更强大的技术吗？为什么存储路径不是一种更常用的技术，为什么不在给定实例中通过 MPTT 使用它们？

另外，如果您认为此分析不完整，请告诉我。

更新：

以下是 MPTT 开箱即用的至少 2 件存储路径解决方案无法做到的事情：

1. 无需任何额外查询即可计算每个节点的子节点计数（如上所述）。
2. 对给定级别的节点施加命令。其他解决方案是无序的。

Answer 1

您也可以考虑我在对 What is the most efficient/elegant way to parse a flat table into a tree? 的回答中描述的 Closure Table 设计

创建/删除/移动节点所需的调用：

• 关闭 = 1

获取树所需的调用：

• 关闭 = 1

获取节点/祖先路径所需的调用：

• 关闭 = 1

获取子节点数量所需的调用：

• 关闭 = 1

获取节点深度所需的调用：

• 关闭 = 1

需要的数据库字段：

• 邻接 = 多 1 个字段/行
• 路径 = 多 1 个字段/行
• MPTT = 2 或 3 个以上字段/行
• 关闭 = 额外表中的 2 或 3 个字段。此表有 O(n^2) 行最坏情况，但远少于大多数实际情况。

还有其他几个注意事项：

支持无限深度：

• 邻接 = 是
• MPTT = 是
• 路径 = 否
• 关闭 = 是

支持参照完整性：

• 邻接 = 是
• MPTT = 否
• 路径 = 否
• 关闭 = 是

我还在我的演讲 Models for Hierarchical Data with SQL and PHP 和我的书 SQL Antipatterns: Avoiding the Pitfalls of Database Programming 中介绍了 Closure Table。

Answer 2

您的结论的问题在于它忽略了使用树木所涉及的大部分问题。

通过将技术的有效性降低到“调用次数”，您实际上忽略了所有易于理解的数据结构和算法试图解决的问题；也就是说，执行速度最快，内存和资源占用少。

对 SQL 服务器的“调用次数”似乎是一个很好的指标（“看起来更少代码”），但如果结果是程序永远不会完成、运行缓慢或占用大量空间，它实际上是一个无用的指标。​​

通过存储每个节点的路径，您并没有创建树数据结构。相反，您正在创建一个列表。一棵树旨在优化的任何操作都会丢失。

这对于小数据集可能很难看到（在许多小树的情况下，列表更好），尝试一些大小为 500、1000、10k 的数据集的示例——您很快就会明白为什么要存储整个数据集路径不是一个好主意。