什么时候可以在 Firebase 中进行嵌套？答案

【问题标题】：When is Nesting OK in Firebase?什么时候可以在 Firebase 中进行嵌套？
【发布时间】：2014-11-20 16:26:53
【问题描述】：

Firebase 的 Structuring Data 文档明确指出“避免构建巢穴”。给出的主要原因是

当我们为 Firebase 中的节点获取数据时，我们还会检索其所有子节点。

考虑到这一点，如果数据仍然正确非规范化，深度嵌套是否仍然有效？

例如，对于带有地理标记帖子和geo-indexes（按帖子语言）的应用，以下是可能的 Firebase 结构：

posts/{postId}
indexes/
        languages/
                  en/geohashes/{geohash}
                  es/geohashes/{geohash}
                  de/geohashes/{geohash}

将此与完全扁平的结构进行比较：

posts/{postId}
index_en_geohashes/{geohash}
index_es_geohashes/{geohash}
index_de_geohashes/{geohash}

我发现第一个嵌套结构干净且自记录。这和平面结构一样有效吗？（假设最常见的用例是“查询语言 x geohashes”）

【问题讨论】：

“它仍然可以接受吗”通常是高度主观的。但是，您需要始终使用 Firebase 数据结构化来回答的问题很简单：我的应用程序中是否经常需要所有语言的地理哈希？如果没有，我通常会将其存储在扁平结构中。但正如我所说：这是主观的，所以任何人都可以不同意。
非常公平 - “可接受”确实是主观的 :) 我删除了它。但是，在“获取德语帖子的所有地理哈希”的简单用例中，这两种结构是否同样有效？
在“获取所有德语帖子”的情况下，它们是等价的。当您开始迭代和过滤数据时，它们就会崩溃。这完全取决于您将如何读取数据，并且根据您迄今为止共享的内容，嵌套结构似乎是有效的。
我认为混淆是因为从角度来看嵌套是相对的。如果您正在访问indexes/languages/en/geohashes，那么您读取的不是嵌套结构。如果您正在访问index_en_geohashes/，则您不是在阅读嵌套结构。当您开始访问indexes/languages/ 时，您正在访问一个嵌套结构并且可能读取的数据超出您的需要。这就是“避免筑巢”的真正含义。
谢谢大家。这是完全有道理的。我了解indexes/languages/ 的查询将返回所有子数据。仍然没有办法只获取子密钥，对吗？

标签： firebase

【解决方案1】：

来自嵌套结构/indexes/languages/en/geohashes/ 和平面结构/index_en_geohashes/ 的查询在计算上是等效的。

【讨论】：

感谢 Kato 和 Leeft 对这个问题的帮助。