为什么没有人在关系数据库树结构的节点上存储一组子 ID？

Question

我正在开发一个爱好项目，它是一个嵌套的待办事项列表应用程序。

我从 Redux 存储库（Javascript 项目）中的 tree view example 开始，它在每个节点上使用 stores an array of child ids 的数据结构。起初我觉得这很奇怪，但在玩过这个结构一段时间后，IMO 很容易维护和推理。

现在我正在研究使用 PostgreSQL 持久化待办事项的最佳方法。我已经广泛阅读了每个解决方案 here (What are the options for storing hierarchical data in a relational database?) 的优缺点，并且即将确定递归 WITH CTE，因为在我的应用程序中写入和更新优先于读取，但我想我应该问.. 为什么在父节点上存储子 ID 不是关系数据库的流行解决方案？

它与Adjacency List 方法最相似，但递归更少，并且您可以获得排序（通过维护child_ids 数组中的顺序）。这似乎也更容易推理，因为您在要求“自上而下”树时不需要反向思考父母。

我已经有了使用这种结构在 Javascript 中交互移动/更新/等节点的逻辑，所以如果我可以使用相同的逻辑来持久化数据，那将是一个巨大的胜利。

Answer 1

为什么将子 ID 存储在父代上不是关系数据库的流行解决方案是有原因的

这个想法非常流行，有两个注意事项，并且在某些建模场景下：

• 由于数据库字段存储单个“事物”，因此将列表存储在“父级”上意味着将列表存储在一个单独的表中，并按 ID 与父级相关，并且
• 由于一个孩子可以属于多个父母，因此执行“一个孩子一个父母”政策变得更加困难。

实际上，DB 将子 ID 存储在父侧的模型将 ID 存储在无人侧，因为您可以像检索父级的子级一样轻松地检索子级的父级 ID。这就是为多对多关系建模时使用此方法的原因。

注意：由于在将父 ID 存储在子节点上时会自动执行一个父节点策略，因此您可以像这样轻松地对树进行建模，同时将内存中的表示转换为邻接列表树。