firestore 文档没有深入讨论使用子集合与顶级集合所涉及的权衡，但确实指出它们的灵 active 和“可扩展性”较低。鉴于您牺牲了在子集合中设置数据的灵 active ，除了精神上令人满意的结构之外，还必须有一些明确的优势。
例如，与从小得多的集合中获取所有项目相比，对大型集合中的单个键进行 firestore 查询的时间如何？
假设我们要为一个家庭单元中的所有人查询一个大型集合“人”。或者，首先按家庭将数据划分为家庭单位。
人 -> 人:{family: 'Smith'}
相对
家庭 -> 家庭:{name:'Smith'} -> 人 -> 人
我希望后者更有效率，但这是正确的吗？每个都有大 O 估计吗？
子集合的任何其他优势(例如交易)？
最佳答案
我有一些关于子集合的关键点，在对数据库建模时需要注意这些点。
1 – 子集合为您提供更结构化的数据库。
2 - 默认情况下对查询进行索引:查询性能与结果集的大小成正比，而不是与数据集的大小成正比。 所以不管你的集合的大小，性能取决于你的结果集的大小。
3 – 每个文档的最大大小为 1MB .例如，如果您的客户文档中有一系列订单，那么为每个客户创建订单子(monad)集合可能是个好主意，因为您无法预测客户将拥有多少订单。通过这样做，您无需担心文档的最大大小。
4 – 定价 :Firestore 会向您收取文档读取、写入和删除的费用。因此，当您创建许多子集合而不是在文档中使用数组时，您将需要执行更多的读取、写入和删除操作，从而增加您的费用。
关于collections - firestore 子集合的优点，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/47193903/