修改后的关闭表用于分层数据的风险和好处
我试图在SQL中存储分层数据并已解决使用
经过相当多的研究，封闭台似乎很适合我的需求。 然而，我一直在阅读的是，如果您想查询特定节点的直接祖先/后代 - 那么您可以在闭合表中使用depth列（参见上述链接的幻灯片68）。 我需要这个depth列来促进这种确切类型的查询。 这一切都很好，但首先关闭表的主要吸引力之一是可以很容易地查询和修改其中包含的数据。并且添加depth列似乎完全破坏了易用性可以修改数据（设想添加新节点并偏移树的整个分支）。
所以 - 我正在考虑修改我的闭包表来定义一个节点和它的直接祖先/后代之间的关系。 这使我仍然可以轻松地穿过树。 查询数据似乎相对容易。 修改数据并不像没有depth字段的原始封闭表格那样容易，但比具有depth字段的表格更容易。 这似乎是一个公平的妥协（几乎在一个闭包表和一个邻接表之间）。
我可以忽略一些东西吗？ 这样做是否放松了封闭台的关键优势之一？ 有没有人看到这样做的内在风险，可能会在后来困扰我？
我相信你失去的关键优势是，如果你想知道一个节点的所有后代或祖先，你现在必须做更多的遍历。
例如，如果您从以下简单的树开始：A-> B-> C-> D
为了得到A的所有后代，你必须去A-> B然后B-> C然后C-> D。 所以，三个查询，而不是一个查询，如果遵循正常模式。
链接地址: http://www.djcxy.com/p/93945.html上一篇: Risks and benefits of a modified closure table for hierarchical data