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