Firestore 子集合与数组

Question

首先，我知道 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 限制的 1MiB 限制。一种可能的解决方法是创建一个单独的文档并将这两个数组拆分为这两个文档。

---

对我来说，子集合的想法似乎是解决这个问题的更“干净”的解决方案，但也许我错过了一些关于为什么这些解决方案中的一个比另一个更好的论点。

我最常见的查询如下（按重要性降序排列）：

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

Answer 1

您问题的答案取决于您想要实现的可扩展性级别。

如果按照设计，您要存储的子数据量有限且非常低，则应该使用数组，因为您减少了文档读取的次数，这意味着更低的成本。

如果您的子数据应该随着时间的推移“无限”增加，您应该使用子集合。

如果您正在构建一个不应该在任何方向上扩展的数据库（概念验证、非常小的业务等），请选择您觉得更舒服的方式。

Answer 2

我正在研究同样的问题...

问题之一是文档中保存的数据是否会超过 1MB（文档的限制）。研究一下 1MB 的纯文本可以容纳多少内容，这真是太麻烦了。但如果它大得令人难以置信，它最终还是会崩溃。因此，如果你以大的方式思考子集合。

如果我们必须使用 Firebase 元素逻辑，答案将是子集合。

不过我想重点是提取的数据。如果您致电用户，您将直接提取该 MB 的数据。相反，如果使用子集合，它不会加载，即使您加载了它，您仍然可以延迟加载。

我想对于您正在做的设置类型来说，是子集合。