Question

我正在制作一个应用程序，并且试图弄清为什么Firestore不赞成使用嵌套集合。该应用程序是一个费用跟踪应用程序，其数据仅与登录用户有关，而该用户从不关心其他任何用户。我发现有两种方法来构造数据。一种使用比另一种更多的嵌套级别。以下结构表示：

collectionName: valueNames
    subcollectionName: valueName

结构1（不是嵌套的）：

user:
    month: totalSpent, startDate, endDate
    transactions: categoryId, amount, timestamp
    categories: monthId, name, totalSpent

结构2（更多嵌套）：

user:
    month: totalSpent, name, startDate, endDate
        categories: name, totalSpent
            transactions: categoryName, amount, timestamp

有人可以告诉我结构1与结构2相比的优势吗？考虑到结构2似乎更易于查询，并且我不必跟踪多个ID，我可以直接获取子集合。这也将使跟踪前几个月的数据更加容易，以便稍后在用户想要分析其支出时向用户显示。

Answer 1

结构1允许您查看多个月内的交易和类别。您无法跨子集合进行查询（请参见Is it possible to query multiple document sub-collections in Cloud Firestore?），因此，使用结构2时，您将无法查询跨月或跨类别的所有交易。

解释

在结构2中，您需要先查询月份，然后选择一个月并查询该月内的类别，然后选择一个类别（或遍历每个月份）并查询该类别中的交易。要汇总当年的类别支出，您需要拨打12个电话，每月一次。

使用结构1，您可以查询所有交易，按日期范围限制，按类别限制或上述各项的组合。您可以一次性查询年份的所有类别，以汇总年份概览的值。结构1为您提供了更多性能查询。

摘要

请记住，Firestore与Firebase Realtime Database不同，您可以在其中一次选择给定树结构中的所有数据。您需要在树的每个级别（每个集合）进行查询以提取数据。

Answer 2

只要您记得随实际文档一起删除它们，创建这些集合就没有错。简而言之，删除文档不会删除它包含的子集合。它是这样工作的：

cloud firestore中的每个文档都包含其中的子集合的引用或路径（而不是整个子集合），因此，删除文档时，每个字段都会被删除，包括存储引用的字段。这意味着实际的子集合现在以垃圾的形式存在，由于删除了它的路径引用，您无法访问该垃圾。

子集合实际上是对自然json数据流的改进，但是由于Cloud Firestore是beta版，因此某些功能（例如删除子集合以及文档）可能会在从Beta或更晚版本毕业时发布。

使用子集合的主要优点是可以保存用户的数据，因为在查询文档数据时不会获取子集合数据。查询很浅。