为什么在 Firestore 中使用嵌套集合不好

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 允许您查看多个月的交易和类别。您无法跨子集合进行查询（请参阅是否可以在 Cloud Firestore 中查询多个文档子集合？），因此使用结构 2，您将无法跨月份或类别查询所有交易。

解释

使用结构 2，您需要首先查询月份，然后选择单个月份并查询该月内的类别，然后选择一个类别（或迭代每个类别）并查询该类别中的交易。要汇总全年的类别支出，您需要拨打 12 次电话，每月一次。

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

概括

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