Question

在重新创建CMS时，我想要替代传统的父/子方法来管理站点地图/页面层次结构。我记得有一段时间看到嵌套的模型，但是不记得它叫什么了。所以，我偶然发现了一个类似的方法，我想评估和比较属性，确保我不会在以后遇到愚蠢的限制，因为我没有采用已经过时间测试的方法。所以，请告知A）它是否已被发明（它叫什么？！），B）属性存在根本缺陷，或者C）这是一个很好的方法（请给出正确的理由！）。

考虑这个清单：

主页
- 关于我们
- 联系我们
- 产品
  - 服装
  - 图书
  - 电子
- 知识库
- 其他东西

在嵌套集模型下，我相信你使用深度优先遍历存储每个节点的左/右描述符：

Home                  1-18
    About Us          2-3
    Contact Us        4-5
    Products          6-13
        Clothing      7-8
        Books         9-10
        Electronics  11-12
    Knowledge Base   14-15
    Other stuff      16-17

这是我开始喜欢的“错误方式”：

Home                  1-9
    About Us          2-2
    Contact Us        3-3
    Products          4-7
        Clothing      5-5
        Books         6-6
        Electronics   7-7
    Knowledge Base    8-8
    Other stuff       9-9

而不是左/右对，我存储ID和LAST_CONTAINED_ID。我发现许多属性都是相同的（或非常相似）：

根节点为ID = 1
对于“叶子”，两个属性都相等，而对于分支，它们不是
任何给定节点的“子节点”总数为LAST_CONTAINED_ID - ID
所有包含的节点都有ID＆gt;容器的ID，但是＆lt; =容器的LAST_CONTAINED_ID
祖先节点的ID <子ID，也是LAST_CONTAINED_ID＆gt; =子ID
深度是祖先节点的SUM

此外，ID提供特定于订单的唯一标识符（没有间隙！）。为了简单起见，我发现存储DEPTH和PARENT参考也更容易，但对于嵌套集来说，这与我的理解基本相同。

那么，这算作嵌套吗？它是否已经是一种常见的方法（但为什么我之前没有听说过......）？我有理由在这个上使用真正的嵌套集吗？

我欢迎你的想法。

Answer 1

它给出的唯一优势是“无间隙”功能，但要实现这一点，您必须更改应用于右值的逻辑。在原始模型中，您可以通过查看所有这些值6来获得“产品”的子项。 ..＆lt; 13，但在你的模型中，你通过看到值4＆lt; ..＆lt; = 7.必须将右值与左值区别对待，使其稍微不那么优雅另一个小抱怨是，在原版中，从12到14的跳跃突出显示你已经改变了水平，而在你的模型中你没有得到这样的视觉提示。
因此，如果您喜欢使用（＆lt;，＆lt; =）代替（＆lt;，＆lt;）那么它可以工作。（因为它似乎是等同的，我不能说'好'或'坏'，但你已经强调了实施较少旅行路径的危险。）

我对任意深度分层数据集的嵌套集的替代方法：好还是坏？

1 个答案: