使用 Firebase 树结构直接表示面向用户的树结构（如“文字处理器”中的“文档大纲”）会有多好/愚蠢？与例如执行 SQL 连接父子类型的关系然后通过投影构建树（这可能会很慢）相反。
我知道嵌套级别限制为 32 级（https://www.firebase.com/docs/web/guide/understanding-data.html），这应该足够了，因为我无法想象一个理智的用户想要为文本树轮廓做尽可能多的嵌套......虽然我可能需要将 32 除以 2，因为每个节点都需要为其子节点和元数据具有子节点，对吗？
我知道一旦通过 Firebase API 访问树节点，则需要获取所有子节点，如果用户有很多数据，这可能是一个性能问题，但最后我认为这不会是一个问题，因为数据主要是用户输入的明文（短）。
如果用户粘贴从某处复制的一些非常长的文本块（例如数十千字节），则可能会出现性能问题。但是然后我可以通过firebase中的一种“符号链接”将这些“TLOB-s”分开，并从不同的节点按需获取它们，对吧？同样应该适用于分离图像和其他重物，对吧？虽然在原型和早期阶段，这可能应该被忽略，为了简单起见......我可能会采用通用方法来“符号链接”，以克服 32 级限制和获取所有子的需要节点一次，对吧？是否有一些最佳实践方法（例如，用于表示与另一个节点的链接的 firebase 节点的语法）？我已将“符号链接”的想法提取到一个单独的问题：Firebase“.
我可能可以将最顶层的节点划分为某些类型的项目/类别，以防止必须绝对获取用户曾经拥有的所有东西......
我的推理/方法正确吗？
是否有任何我没有想到的考虑因素，例如对数据大小或性能的先天限制或例如安全规则？
其他技术（例如 Couchbase/Pouchbase）会更好地为我服务吗？
更多细节：这是一个混合移动应用程序，也强调网络访问和离线访问。我希望在 Javascript 中完成大部分逻辑。问题的 UI 部分在这里：HTML tree for hybrid mobile app。