【发布时间】：2020-02-02 03:32:53
【问题描述】：
我正在开发一个 React-Native 应用程序，并将我的数据托管在 Cloud Firestore 中。我有这种情况，我需要存储“restaurant_menu”，其中包含所有餐厅的菜单。 所以，我想知道这两种方法中哪一种更好。
1. restaurants_menu(collection) -> menu1(document) -> field1, field2, field3, ...
2. restaurants_menu(collection) -> resturant1_menu(document) -> resturant1_menu (sub-collection) -> field1, field2, field3, ...
我担心第一种方法稍后会创建一个巨大的文档列表，所以相反，我认为第二种方法可能更好，因为它为每个餐厅创建一个文档，然后为每个菜单创建一个子集合。
我在非 SQL 数据库方面不是很有经验。
【问题讨论】：
-
真的没有所谓的“坏”模型，只有模型不能满足您的应用程序的需求。您将必须定义所有预期的读取和写入操作，以及您实际打算存储多少数据。最佳模型将源自您陈述的用例。同样，我建议发布到 Reddit 等讨论组，这样你就有空间发现你真正需要什么，因为这个问题不只有一个正确的答案。 reddit.com/r/Firebase
-
@DougStevenson 但我确实解释了我的情况。当菜单集合增长时，该集合中将包含许多文档，因此为避免这种情况，最好在文档中创建以每个餐厅 ID 命名的子集合？
-
那么，您是说菜单项的数量将会增长？有上限吗？您打算如何查询它们以填充您的 UI？
-
@DougStevenson 是的，菜单项的数量将会越来越多，因此为了避免拥有大量文档，我想为每个餐厅创建一个文档，其中将包含带有菜单项的文档集合。随着时间的推移，将有成千上万的这些项目。这不是创建子集合的好方法吗？
-
Firestore 不存在“巨大”集合的问题。集合的大小 - 文档的数量 - 基本上是无限的。单个文档中字段的大小限制为 1MB。除了这些，你还关心什么？您打算如何查询这些数据以填充您的 UI？
标签： firebase react-native google-cloud-firestore nosql