在 Firestore 中存储用户特定数据/配置文件的最佳做法

Question

我的锻炼应用程序包含以下数据结构

1. 用户配置文件（独立 - 1:1）
2. 锻炼资料（白天计划的父母 - 1:N）
3. 日间计划简介（练习的父母 - 1:N）
4. 锻炼资料（父组 - 1:N）
5. 设置配置文件（独立 - 1:1）

从某种意义上说，所有这些都是相互关联的，即 1 个用户只能有 1 个锻炼视图模型。 基于我对数据模式的了解和对关系数据库的一点经验，我设计了一个如上所述的“非规范化”数据结构。 我希望这就是亚历克斯在这个 SO 查询中的回答所暗示的 - 在 Firestore 中构建此类数据的正确方法是什么？

在初始阶段，我使用后端 AppScript 将原始数据上传到 Firestore 用于锻炼、日间计划、锻炼和设置资料。 之后，我的应用程序将创建一个用户，该用户将从 Firestore“读取/获取”锻炼模板，使用“ userID/uid ”将用户特定的锻炼数据“创建/发布”到 Firestore。 rest 的配置文件也是如此，其中应用程序需要从 Firestore“读取/获取”配置文件模板并添加“ userID/uid ”以创建用户特定的配置文件到 Firestore。

重新登录后的后续“读取/获取”操作将简单地使用“用户ID/uid ”来“读取/获取”现有的用户特定配置文件。 通过这些操作，我对我的数据模式设计有一些疑问，如下所示。

问题 1

1. 如果用户希望锻炼时间超过 6 个月，“阅读/获取”一些子配置文件（例如锻炼和套装）可能会超过 500。

我读到 Firestore 查询将自身限制为 500 个文档，我们需要在本机代码中部署一些“操作计数器”来解决这个问题，并检索超过 500 个文档。 但是这样做可能需要从 Firestore 服务器检索超过 10 秒的数据，不是吗？

我还没有尝试过，但是当我通过后端 Appscript 上传超过 1000 条记录（来自 google sheet）时，花了很长时间，超过 2~3 分钟。 还是通过 AppScript 上传数据比使用应用程序读取/写入 Firestore 慢得多？

问题 2

在这一点上，我什至还没有触及安全规则。 现在，让管理员（比如我自己）有权访问所有配置文件（通用模板和特定于用户的模板）并让用户仅访问他们自己的用户特定配置文件似乎就足够了。

我应该注意哪些管理 Firestore 的标准/最佳实践？

请随时分享任何其他有用和建设性的反馈。