Firestore 在嵌套方面推荐的数据结构是什么？深入还是保持平坦？

Question

我想 firebase 不太喜欢嵌套，但他们也说（如果我理解正确的话）一级嵌套是可以的。

让我们看一个餐厅和 2 个不同场景的示例：

Flat：无嵌套（无子集合）

/restaurants
    -mealCategoriesID: List<DocumentReference>
    -mealsID: List<DocumentReference>

/meal_categories

/meals
    -mealCategoryID: DocumentReference

深：筑巢

/restaurants/meal_categories/meals

那么，在这个餐厅示例中最好的方法是什么？

Answer 1

当谈到 NoSQL 数据建模时，不存在单一的“最佳”模型。这完全取决于您想要如何使用这些数据。

在 Firestore 支持集合组查询之前，将项目存储在一些顶级列表中通常是有意义的，以便您可以查询它们。这将是您的第一个模型，它始终允许您查询所有餐点，无论什么餐厅或类别。

但通过集合组查询，您现在可以随时查询所有餐食，因为它们位于同名的集合中。在这个阶段，将它们分布在多个子集合中实际上有助于提高写入吞吐量，因为这些子集合更有可能分布在磁盘上。

让您的模型与众不同的一件事是能够查询特定类别的膳食。

• 假设您想要查询所有餐厅中特定类别的餐食。在您的最后一个模型中，只有当您还将 存储category ID在每个膳食文档中时才可能实现。

• 同样，假设您想要查询特定餐厅或餐厅子集的餐食中特定类别的餐食。为了允许这样的查询，每顿饭都需要有一个category ID 和一个restaurant ID字段。

在上述两种情况下，您都会复制数据以允许某些查询。但执行一些嵌套通常仍然更好，因为如果您达到了重要的使用量，它可以提供更好的写入并发/吞吐量。

请注意，每个数据模型的读取和查询性能都是相同的，因为 Firestore 仅允许可以保证性能的用例。