我试图在SQL中存储分层数据并已决定使用
-
一个对象表，其中包含所有主要数据
-
和一个闭包表，定义了对象之间的关系（read more on closure tables here [slides 40 to 68]） .
经过相当多的研究，闭合表似乎很适合我的需求 . 但是，我一直在阅读的一件事是，如果你想查询特定节点的直接祖先/后代 - 那么你可以在闭包表中使用 depth 列（参见上面链接中的幻灯片68） . 我需要这个 depth 列来促进这种确切类型的查询 . 这一切都很好，但首先关闭表的主要吸引力之一是可以轻松查询和修改其中包含的数据 . 并且添加 depth 列似乎完全破坏了易用性可以修改数据（想象添加新节点并偏移树的整个分支） .
所以 - 我正在考虑修改我的闭包表来定义关系 only between a node and its immediate ancestor / descendant . 这使我仍然可以轻松遍历树 . 查询数据似乎相对容易 . 修改数据并不像没有 depth 字段的原始闭包表那么容易，但比具有 depth 字段的数据容易得多 . 这似乎是一个公平的妥协（几乎在闭包表和邻接表之间） .
我忽略了什么吗？我是否通过这种方式失去了关闭表的一个关键优势？有没有人看到这样做的任何固有风险可能会在以后困扰我？
1 回答
我相信你失去的关键优势是，如果你想知道一个节点的所有后代或祖先，你现在必须做更多的遍历 .
例如，如果从以下简单树开始：A-> B-> C-> D.
为了获得A的所有后代，你必须去A-> B然后B-> C然后C-> D.因此，三个查询，而不是单个查询，如果遵循正常模式 .