mongodb DB design for shop chain

0
votes

Using mongo. The app needs to allow shopping at different kinds of locations. Shops share some of the products in their offer, some are unique. Each shop sets their own prices for each product (many might probably be the same prices but that's not clear yet, probably not).

My approach so far was to create a Product model, which would just have the name, description, and category.

Then, for each shop, there would be a PriceList created, by associating a price to each Product, and thus having for a particular shop only products on offer which they actually sell.

But how to model this association? If I have a PriceList for which I reference a Product (e.g. by ID), then when browsing products, wouldn't that generate a huge overhead in that to generate the shop's pricelist there would be pricelist.length amounts of queries querying the Product model for the names and their categories?

The other idea I had was to have every pricelist have a list of all products with names, description, category and price, but then generating a new pricelist for a new shop seems to be cumbersome, as there's no independent Product list from which to copy over items?

Any other suggestion?

2
node.jsmongodbdatabase-design

2 Answers

1
votes

You may have already considered this, but just in case you need to make sure using a NoSQL database (like MongoDB) is the right solution for your problem.

The benefit of using an RDBMS is that you can normalize data and easily do joins. So, products in one table, pricing in another and run a query and pull data from both tables. It sounds like you are already coming from this world and probably understand the concept of joins.

NoSQL does not have joins the same way by design and for that reason it is not always the best fit. Rather data is thought of in terms of "documents" and collections. NoSql does a great job with hierarchical data but in many cases the data must be duplicated.

If you have a large amount of duplicated data between shops and their products/prices, then using a regular relational db is probably best.

If you still want to use MongoDB you have two options.

  1. Put product/pricing data with each shop document and be ok with probably duplicating data.
  2. Put product/pricing data in a separate collection and query it just when you need it for each shop.

Of course it depends on your architecture, but I would lean towards #2 above because you can always combine a query with a list of shops at the same time and optimize things that way. A split design might also be better in the long-run if your data grows. If the two collections get large enough you can easily put them on different nodes and see the real power behind MongoDB.

Best of luck!

0
votes

How about something like this:

Shop = {
    "Pricelist": {
                   "1": 2.99,
                   "5": 3.99
               }
}


Product = {
    "id": "1",
    "name" : "Lego"
}

Note that 1 and 5 inside Pricelist refer to product ids. In this way, every shop could set it's own prices for products.