MongoDB带数组的大型文档与小型多文档

我们有一个食品配送应用程序。我们使用了MySQL，但现在正在迁移到MongoDB

我们有这样的桌子：餐厅、菜单、订单等等

对于迁移MongoDB，我不知道应该如何为“菜单”集合设计模式

选项1） 使用与MySQL相同的方法，“菜单”集合将有许多来自不同餐厅的菜单（文档）

选项2） 每个商店在“菜单”集合中都有一个文档，将菜单嵌入到文档中

总之，哪一个最适合MongoDb？20000个小文档vs 100个文档，每个文档中包含100或200个数组/对象。 我问的是性能，以及这个应用程序是否会随着数十家新餐厅的发展而增长

每个菜单文档几乎都是256字节，计算起来，我们可以很容易地说每个商店都有50到200个菜单。（因此我们不会超过MongoDB的16MB文档限制）

此外，我们还需要在两个不同的页面上使用应用程序中的“菜单”，第一个页面：20种来自附近不同餐厅的最佳食物，第二个页面：每个商店都有自己的页面和菜单

---

注：当一家餐厅添加所有菜单时，其菜单至少保持98%不变6-8个月。除了价格或小细节之外，它们不容易修改/编辑或更改。

在MongoDB中，您可以将数据存储为您以后想要读取的格式

因此，您需要分析您的用例：

• 20种来自不同餐厅的最佳食物，适合您附近的位置
• 每个商店都有自己的页面和菜单

我不确定第一个用例，但看起来你总是先过滤餐厅（位置），所以在这种情况下，将菜单项与餐厅一起存储

如果您想直接对菜单项进行筛选，您可以将它们存储在具有专用索引的单独集合中。在您的情况下，如果您将地理位置添加到每个不同的菜单项（非规范化），这也可以起作用

---

您还可以同时执行这两项操作：将菜单项存储在餐厅文档中并作为单独的文档。

通常，当您从关系型RDBMS迁移到NoSQL数据库时，将每个表逐个迁移到集合并不是明智的做法。您的问题没有太多细节，但我倾向于选项2。谢谢，这些与我的想法不同，但是如果我们想为菜单（每一个）添加评级/评论，是否仍然最好使用选项2？此外，在API发送菜单之前，我们在后端将菜单解析为菜单类型（膳食、饮料、甜点等），因此，如果我们使用以下方式进行存储是否是一种好方法：菜单集合->存储->菜单类型1--菜单，菜单类型--2--菜单对于评级/评论，我将为此创建一个单独的集合，并且仅将平均评级复制到实际的菜单项。