firebase - Firestore子集合与数组

首先，我知道Firestore的工作方式，并花费了大量时间，评估了一种好的结构的不同方法。我仍然在考虑以下情况:

有一个已知配方的数据库。用户可以添加配方，但是必须确认它们是真实的配方，而不仅仅是一些变化。因此，每个用户都可以从用户生成的食谱列表中选择食谱，以表明他们知道如何 cooking (或添加新食谱)。

现在，我希望用户与其他人共享他们的食谱 list ，但是我不确定在哪里可以使用Firestore最好地做到这一点。诀窍是，我想一次显示所有食谱，并且不想对它们进行分页。

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

子集合

每当用户共享他的列表时，查看该列表的用户将必须加载食谱的整个列表，这可能导致大量的文档读取(我想实际上是〜50，在极少数情况下可能是1000)。

优点:

更自然的结构

易于维护(例如，删除食谱，检查是否存在特定食谱)

易于添加字段(例如timeOfCreation，comment，personalRating等)

缺点:

从长期运行

可能导致大量读取

数组

我可以将用户文档(或单个子文档“KnownRecipes”)中的每个已知配方(id和imageURL)保存在数组中。该数组可以采用以下形式

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限制。可能的解决方法是创建一个单独的文档，然后将这两个数组拆分为这两个文档。

对我而言，使用Subcollections的想法似乎是解决此问题的更“干净”的解决方案，但也许我缺少关于为什么其中一种解决方案优于另一种解决方案的争论。

我最常见的查询如下(按重要性降序排列):

用户可以 cooking 哪些食谱

将用户可以 cooking 的食谱添加到用户列表

谁可以 cooking 特定食谱(有食谱-> Cooks子集合)

更新用户可以 cooking 的现有食谱

最佳答案

我正在研究同一个问题...
问题之一是文档中保存的数据是否会超过1MB，这是文档的限制。研究一下它可以在1MB的纯文本格式中保存多少，这实在是太难了。即便如此，如果它变得不可思议，它最终也会崩溃。因此，如果您以很大的方式思考子集合。
如果必须使用Firebase元素逻辑，答案将是子集合。
我仍然认为最主要的是要提取的数据。如果您致电该用户，您将直接提取该MB数据。而是使用子集合将不会加载，即使您加载了它也仍然可以延迟加载。
我想您正在进行子集合的那种设置。