Cloud Firestore 结构更好的案例

Question

我正在开发一个应用程序，用户 (firebase auth) 将在其中注册他们的费用，并在每个星期天通知 (OneSignal) 将在一周内到期的费用。 我的 Firestore 结构是：

-users (collection)
---xxXXxxX (user document)
-----email
-----OneSignal ID
-----expenses (collection)
-------yyYYYyY (expense document)
---------dueDate
---------value
---------userId
-------aaAAaaA (expense document)
---------dueDate
---------value
---------userId
---bBBbbBB (another user document)
-----email
-----OneSignal ID
-----expenses (collection)
-------wwWWwwW (expense document)
---------dueDate
(...)

基于这种结构，每个星期日 Google Cloud 都会运行一个计划函数，该函数将查询当周到期的所有费用（集合组查询 - 返回每个用户可能有多个费用的费用列表。）

有了这个仍然有效的列表，我将手动将 userId 与费用分开，创建第二个列表，每个用户有一个寄存器。使用第二个列表，该函数将获取每个用户的 OneSignal ID（firebase 上的另一个查询，列表中每个用户一个）并在 OneSignal 服务中为每个用户注册一个通知。

P.S：OneSignal ID 可以更改，因为这种情况我无法自费保存 OneSignalID。

我猜这个结构会起作用，但似乎这不是最好的解决方案，因为许多查询在“后台”上运行，这在未来可能会很昂贵。

对于这种情况，有人有更好的建议吗？也许火库上的另一个结构......

我希望我能很好地解释“问题”。英语不是我的第一语言。

谢谢！

Answer 1

根据我在文档中阅读的内容，您做得很完美，这就是原因（任何人，如果我错了，请纠正我）

1. 当用户下载超过 Xgb 的数据时，Firebase 会向您收费。据我所知，您不会为查询和过滤付费。所以你在这方面做得很好。

2. Firebase Firestore 查询时间完全取决于您获得的结果数量。结构无所谓。因此，如果您对这种结构感到满意，请坚持下去。我觉得一点问题都没有。

编辑：我刚刚重新阅读了文档并发现了这一点：

当您使用 Cloud Firestore 时，您需要支付以下费用：

• 您执行的读取、写入和删除的次数。
• 数据库使用的存储量，包括元数据和索引的开销。
• 您使用的网络带宽量。

因此，您显然会在查询时被收费。在这种情况下，构建数据库的更好方法可能是展平费用树。你可以有这样的东西

Users - - - -
             |------
             |------

Expenses - - - - -
                     user ID - - -
                      Etc---------
                      Etc----------

这样您就可以过滤用户的查询。 https://cloud.google.com/firestore/docs/query-data/queries#:~:text=Cloud%20Firestore%20provides%20powerful%20query,Data%20and%20Get%20Realtime%20Updates.