问题描述
首先，我知道FiRestore是如何工作的，并且花了很多时间，评估了不同的方法来构建一个好的结构。不过，我仍在考虑以下情况：有一个已知食谱的数据库。用户可以添加食谱，但必须确认它们是真正的食谱，而不仅仅是一些变体。因此，每个用户都可以从用户生成的食谱列表中选择Receipe来声明他们知道如何烹饪(或添加新的食谱)。
现在我希望用户与其他人共享他们的接收列表，但这正是我不确定如何使用FiRestore最好地实现这一点的地方。诀窍是，我想一次显示所有食谱，而不想对它们进行分页。我目前正在评估两种可能性：
子集合
每当用户共享他的列表时，查看该列表的用户将不得不加载整个食谱列表，这可能会导致大量的文档读取(我认为实际情况下约为50，在极少数情况下可能为1000)。
优点：
更自然的结构 更易于维护(例如，删除配方、检查特定配方是否存在) 更容易添加字段(例如，TimeOfCreation、Comment、PersonalRating等)缺点：
在长期运行时可能会导致大量读取数组
我可以将每个已知食谱(id和ImageURL)保存在用户的文档中(或保存为数组中的单个子文档"KnownRecipe")。此数组的形式可以为
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限制。一种可能的解决方法是创建一个单独的文档，并将这两个数组拆分为这两个文档。对我来说，子集合的想法似乎是这个问题的更"干净"的解决方案，但可能我错过了一些关于为什么其中一个解决方案比另一个更好的论点。
我最常见的查询如下(按重要性降序)：
用户可以烹饪哪些食谱 将用户可以烹饪的食谱添加到用户列表 谁可以烹饪特定的食谱(有一个食谱->Cooks子集合) 更新用户可以烹饪的现有食谱推荐答案
问题的答案取决于您要实现的可伸缩性级别。
如果根据设计，您要存储的子数据量有限且非常低，则应使用数组，因为您减少了文档读取次数，这意味着更低的成本。
如果您的子数据应该随着时间的推移无限增加，则应使用子集合。
如果您正在构建一个不应该向任何方向扩展的数据库(概念验证、非常小的企业等)只要你觉得更舒服的就去吧。