问我的警报原生于任意深度层次数据集的嵌套集:好还是坏？

EN

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

考虑一下这份清单：

美国

• Clothing
• Books
• Electronics

• Home
  • 联系我们
  • Products

​

- Knowledge Base
- Other stuff

​

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

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

• The

• 表示“叶”，而对于分支，它们不是

• ，任何给定节点的“子节点”总数为LAST_CONTAINED_ID - ID

• ，所有包含的节点都有一个ID >容器的ID，但是容器的

祖先节点有一个ID<子ID，但也有一个LAST_CONTAINED_ID >= --子IDH 134，深度是祖先节点的总和H 235F 236

此外，ID还提供一个特定于订单的唯一标识符(没有空白！)。为了简单起见，我还发现更容易存储深度和父引用，但据我所理解，嵌套集也是如此。

那么，这算得上是嵌套集吗？这是否已经是一种常见的方法(但为什么我以前没有听说过.)？有什么好的理由让我对此使用真正的嵌套集呢？

我欢迎你的想法。