Firestore子集合与阵列

Question

首先，我知道Firestore是如何工作的，并且花了很多时间评估不同的方法以获得良好的结构。但我仍在考虑以下情况：

有一个已知食谱的数据库。用户可以添加菜谱，但必须确认它们是真正的菜谱，而不仅仅是一些变体。因此，每个用户都可以从用户生成的食谱列表中选择receipes，说明他们知道如何烹饪（或添加新的）。

现在，我希望用户与其他人分享他们的receipes列表，但我不确定如何最好地使用Firestore实现这一点。诀窍是，我想一次展示所有的食谱，而不想给它们分页。

我目前正在评估两种可能性：

每当用户共享他的列表时，查看所述列表的用户将不得不加载整个食谱列表，这可能会导致大量的文档阅读（我想实际上大约50，在极少数情况下可能是1000）。

优点：

• 更自然的结构

欺骗：

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

我可以将用户文档中的每个已知配方（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限制可能会达到。一种可能的解决方法是创建一个单独的文档，并将这两个数组html" target="_blank">拆分为这两个文档

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

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

• 用户可以烹饪哪些食谱
• 将用户可以烹饪的食谱添加到用户列表中
• 谁可以烹饪一个特定的食谱（有一个食谱-

Answer 1

键是另一个集合的con/pro

键有助于避免重复；但这需要考虑什么是duplicate的定义（它可能会改变）；

数组的无键行为可以通过auto-id进行模拟。

p. s.@托马斯在问题中列出的利弊非常有帮助。

Answer 2

我在研究同一个问题。。。

其中一个问题是文档中保存的数据是否会超过1MB，这是文档的限制。研究一下1MB的纯文本可以保存多少，这是一个很大的问题。尽管如此，如果它变得难以置信，它最终会崩溃。因此，如果你以大的方式思考子集合。

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

尽管如此，我想主要的一点是提取的数据。如果您调用用户，您将直接提取该MB数据。相反，对于子集合，它不会加载，即使您加载它，您仍然可以延迟加载。

我猜对于你正在做的子集合的设置。

Answer 3

你的问题的答案取决于你想要达到的可伸缩性水平。

如果通过设计，希望存储的子数据量有限且非常低，那么应该使用数组，因为这样可以减少文档读取的次数，这意味着降低成本。

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

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