首先，我知道Firestore是如何工作的，并且花了很多时间来评估不同的方法来构建一个好的结构。我仍然在考虑以下场景：
这里有一个食谱数据库。用户可以添加食谱。每个用户都可以从用户生成的食谱列表中选择他们知道如何烹饪的食谱。
现在我希望用户与其他人分享他们的食谱列表。这是我不确定如何使用Firestore最好地完成的地方。诀窍是，我想一次显示所有的食谱，而不想给它们分页。
我目前正在评估两种可能性：

子集合

每当用户分享他的列表时，查看该列表的用户将不得不加载整个食谱列表，这可能导致大量的文档读取（我认为实际上约50，在非常罕见的情况下可能是1000）。
优点：

• 更自然的结构
• 更易于维护（例如删除配方，检查是否存在特定配方）
• 更容易添加字段（例如timeOfCreation，comment，personalRating，...）

缺点：

• 从长远来看可能会导致大量的读取

数组

我可以将每个已知的食谱（id和imageURL）保存在用户文档中（或者作为一个单独的子文档“KnownRecipes”），保存在一个数组中。这个数组可以是

recipesKnown: [{rid: 293ndwa, imageURL: image1.com, timeAdded: 8371201332}, 
               {rid: 9012831, imageURL: image1.com, timeAdded: 8371201871},
               {rid: jd812da, imageURL: image1.com, timeAdded: 8371201118},
               ...
              ]

优点：

• 我只需要一个文档读取每当有人想看到另一个用户的名单
• 阅读用户的列表可能更快

缺点：

• 很难更新特定的食谱（例如有人想更改imageURL：我需要在本地更改列表，并将整个文档作为更新发送到服务器-因为我不能只更改数组中的单个元素）
• 当用户决定拥有大约1000个配方时（这可能永远不会发生，但它可能会发生），可以达到Firestore限制的1 MiB限制。一个可能的解决方法是创建一个单独的文档，并将这两个数组拆分为这两个文档。

对我来说，子集合的想法似乎是这个问题的更“干净”的解决方案，但也许我错过了一些关于为什么其中一个解决方案上级另一个的论点。
我最常见的查询如下（按重要性降序排列）：

• 用户可以烹饪哪些食谱
• 将用户可以烹饪的食谱添加到用户列表
• 谁可以烹饪特定的食谱（有一个食谱->厨师子集合）
• 更新用户可以烹饪的现有食谱