新的 Firebase Firestore DocumentDb 如何为大型子集合建模答案

【问题标题】：How does the new Firebase Firestore DocumentDb model large subcollections新的 Firebase Firestore DocumentDb 如何为大型子集合建模
【发布时间】：2018-03-17 04:17:30
【问题描述】：

在 firebase 实时数据库中，您通常会将大型子集合移出到它自己的单独集合中。例如，如果用户可能有大量关注者，则数据模型可能会在用户对象中保留关注者数组，但将关注者移出到单独的集合中。

用户

用户ID
- 用户名
- 以下：[]
  - 用户ID
  - 用户名

关注者

用户ID
- followerUserId

您是否必须使用新的 Cloud Firestore 进行相同类型的建模，或者您是否可以在查询中使用投影，这样您就不会在每次扫描时都返回一个大的子集合。听起来子集合存储在自己的完整集合中，所以这可能会提高存储子集合的效率？

【问题讨论】：

标签： firebase firebase-realtime-database google-cloud-firestore

【解决方案1】：

我认为您根本不必这样做，因为获得Document 不会从子集合中下载其他人。也就是说，它在 实时数据库 中并没有真正的劣势。

我在短时间内找不到提到它的其他来源，所以请查看this video。这是 Android 的“入门”视频，大约 40 秒（从我的链接中提供的时间戳）他准确地提到了我所说的和Todd Kerpelman 的声明：“[...]常见的是包含一堆文档的集合，然后指向包含其他文档的子集合等等。”，基本上意味着团队期望这种类型的数据存储。

【讨论】：

太好了，这个视频很有帮助。我看到它们支持数组和子集合，firebase.google.com/docs/firestore/solutions/arrays 一个与另一个的用例是什么？
@MonkeyBonkey 这将被获取，因为它是文档的一部分，但子集合不是文档的一部分，这就是为什么一旦文档被删除它们也不会被删除，您将拥有删除所有子集合文档：firebase.google.com/docs/firestore/manage-data/…。而且也没有对数组的查询，所以可以考虑这两点。

【解决方案2】：

Firestore 允许使用任何一种结构。对于大多数操作，一旦您将网络延迟混入其中，两者的效率都不会明显高于其他操作。

与实时数据库不同，Firestore 中的查询默认是浅层的，因此如果您确实在用户中嵌套了关注者，则查询用户不需要加载他们的所有关注者。这意味着您没有必须单独存储关注者。

在子集合结构中，您还可以使用collection group queries 来查询具有相同ID 的所有子集合。

【讨论】：