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