在 firebase 实时数据库中，您通常会将大型子集合移出到它自己的单独集合中。例如，如果用户可能有大量关注者，则数据模型可能会在用户对象中保留关注者数组，但将关注者移出到单独的集合中。
您是否必须使用新的 Cloud Firestore 进行相同类型的建模，或者您是否可以在查询中使用投影，这样您就不会在每次扫描时返回大型子集合。听起来子集合存储在他们自己的完整集合中，所以这可能会提高存储子集合的效率？
Firestore 允许任何一种结构。对于大多数操作，一旦您将网络延迟加入其中，两者都不会明显比另一个更有效。
与实时数据库不同，Firestore 中的查询默认情况下很浅，因此如果您确实在用户中嵌套了关注者，则查询用户不需要加载他们的所有关注者。这意味着您不必单独存储关注者。
在子集合结构中，您还可以使用集合组查询来查询具有相同 ID 的所有子集合。
我认为您根本不必这样做，因为获得 aDocument 不会从子集合中下载其他人。也就是说，它在实时数据库中并没有真正的缺点。
我找不到在短时间内提到它的另一个来源，所以看看这个视频。这是 Android 的“入门”视频，大约 40 秒（从我的链接中提供的时间戳）他准确地提到了我所说的话和Todd Kerpelman的声明：“[...]包含一堆文档的集合，然后指向包含其他文档的子集合，依此类推。” ，基本上意味着团队期望这种类型的数据存储。