3

关于我关于建模一个真正的面向用户的树结构的另一个问题（使用 firebase 树结构直接表示“文档大纲”结构），我正在考虑在某些嵌套级别上实施一种通用的“符号链接”方法，以克服 32 个嵌套级别的限制以及一次获取所有子节点的需要。

firebase 中的“符号链接”是否有一些“最佳实践”？

例如：

  • firebase 节点的语法（内容、键值结构），它象征着到另一个节点的链接
  • 符号链接应该包含到目标节点的路径（绝对的还是相对的？）还是只是某种全球唯一的 id？
  • 符号链接内容完成异步加载时触发的回调 API

我正在设想一个小包装 API，它将抽象节点是否真的存在或是否通过“符号链接”间接访问的差异。可能有一个额外的 API 方法“现在获取我这个/更多”，因为用户想要更多关于显示数据的详细信息（例如在树中深入挖掘），它可以获取例如下一级嵌套（通过回调），抽象出孩子们的内容是真的存在还是只是符号链接......

总的来说，这似乎是个好主意吗？

4

1 回答 1

0

也许你应该看看关系世界是如何解决这个问题的。我们可以通过首先将树节点转换为文档来采用他们的解决方案。这意味着对于一棵树

root 0
|-- top child I
+-- top child II
    |-- second-level child 1
    |   +-- third-level child a
    |-- second-level child 2

您将拥有六个树节点中的每一个的文档。然后在描述树结构的文档中添加额外的数据。

我受到了这个 SO 答案的启发，它概述了三种方法的优缺点。让我在这里展示这些方法如何应用于面向文档的数据库。

使用父 ID 的方法

添加一个parentId包含文档 id 或父节点的其他一些唯一值的字段。

pros and cons:
+ easy to understand, cheap insert, cheap subtree move
- difficult to retrieve subtree

改进的先序树遍历

添加两个字段left并right包含遍历的索引。首先从根节点开始并分配 1 到left，然后下降到top child I并分配 2 到left。如果没有更多的孩子，将下一个整数分配给right。然后上一层并将下一个整数分配给right。

有关更多详细信息，请参阅这个古老但仍然非常出色的指南：Modified Preorder Tree Traversal on Sitepoint。

pros and cons:
+ cheap retrieve of subtree, ordering of children guaranteed
- difficult to understand, expensive insert (repeat tree traversal)

将路径保存在节点中

使用一些唯一值（如文档 ID）并创建这些唯一值的路径，从根开始并下降到节点。例如，第二级孩子 2 的路径可能是"0/II/2". 或者创建一个数组['0', 'II', '2']。

pros and cons:
+ cheap retrieve of subtree, cheap insert
- expensive subtree move
于 2017-11-30T13:23:19.107 回答