Reputation: 785
We have a food delivery app. We used MySQL but we are migrating to MongoDB now.
We have tables like this: Restaurants, menus, orders, etc...
To migrating MongoDB, I'm confused with how should I design schema for the 'menus' collection
Option 1) Use the same way with MySQL, the 'menus' collection will have a lot of menus (documents) from different restaurants
Option 2) Each store will have one document in the 'menus' collection, embed their menus into their document
To summarize, which one is best for MongoDb? 20000 small document vs 100 documents and each document contains 100 or 200 array/object inside of it. I'm asking for performance and if this app grows with tens of new restaurants
Every menu document is almost 256 byte, for calculation, we can easily say each store will have menus between 50 and 200. (So we will not exceed the 16MB document limit of MongoDB)
Also, we need to use 'menus' in-app on two different pages, first one: 20 best food from different restaurants for your near location, the second one: each store will have its own page with their own menus.
Note: When a restaurant adds all of their menus, their menus stay 98% the same for at least 6-8 months. They don't modify/edit or change easily except price or little details.
Upvotes: 0
Views: 736
Reputation: 17846
In MongoDB, you store your data in the format you will want to read them later.
So you need to analyse your usecases:
I'm not sure about the first use case, but it looks like you're always going to filter on restaurant (location) first, so in that case store the menu items with the restaurant.
If you want to filter directly on menu items, you would store them in a separate collection with dedicated indices. In your case, that could work too, if you add (denormalize) the geo location to each different menu item.
And you can also do both: store the menu items in the restaurant document ánd as separate documents.
Upvotes: 2