Firebase“符号链接”到另一个节点 [英] Firebase "symlink" to another node

问题描述

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

In relation to my other question about modelling a real user-facing tree structure (Using firebase tree structure to represent a "document outline" structure directly), I was thinking of putting in place a generic approach to "symlinking", at certain nesting levels, to overcome the 32 nesting levels limitation and the need to fetch all sub-nodes at once.

firebase中是否有一些最佳做法用于符号链接 ？

例如：

• 语法（内容，关键字-值结构）的Firebase节点，它象征着到另一个节点的链接


• 符号链接应包含目标节点的路径（绝对还是相对）或只是某种全局唯一ID ？


• 用于回调的API，当符号链接内容完成加载asyn时将触发该回调

我正在预想一个小的包装器API，该API可以抽象出该节点是否真正存在还是可以通过符号链接。由于用户需要更多有关显示数据的详细信息（例如，在树中更深地钻取），因此可能会有一个额外的API方法现在，让我/更多。下一层嵌套（通过回调），抽象出孩子们的内容是真的存在还是只是符号链接...

I am envisioning a little wrapper API which would abstract the difference of whether the node is really there or is it accessed indirectly via "symlink". There could be an extra API method "now fetch me this/more" as the user wants more details on the displayed data (e.g. drilling down deeper in the tree), and it could fetch e.g. the next level of nesting (via callback), abstracting away whether the children's content was really there or just symlinked...

这似乎是个好主意吗？一般而言？

推荐答案

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

Perhaps you should look at how the relational world solves this problem. We can take their solutions by first transforming the tree nodes to documents. This means for a tree

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

您将为六个树节点的每一个都有一个文档。然后在描述树结构的文档中添加其他数据。

you will have a document for each of the six tree nodes. Then have additional data in the documents describing the tree structure.

我受到此SO答案概述了三种利弊方法。让我在这里展示这些方法如何应用于面向文档的数据库。

I have been inspired by this SO answer which outlines three approaches with pros and cons. Let me show here how these approaches apply for a document-oriented database.

具有父ID的方法

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

Add a field parentId which contains the document id or some other unique value of the parent node.

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

修改后的预排序树遍历

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

Add two fields left and right to contain the indexes of the traversal. First start with the root node and assign 1 to left, then descend to top child I and assign 2 to left. If there are no more children, assign the next integer to right. Then go up one level and assign the next integer to right.

有关更多详细信息，请参见此旧但仍然出色的指南：在站点上修改的预排序树遍历。

For more details, please see this old but still excellent guide: 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）并创建以下路径这些唯一值以root开头，然后下降到节点。例如，第二级子级2的路径可能是 0 / II / 2 。或创建一个数组 ['0'，'II'，'2'] 。

Use some unique value (like the document id) and create a path of these unique values starting with root and descending down to the node. For example the path for the second level child 2 might be "0/II/2". Or create an array ['0', 'II', '2'].

pros and cons:
+ cheap retrieve of subtree, cheap insert
- expensive subtree move

这篇关于Firebase“符号链接”到另一个节点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！