> The example is that if you have 10 rakes in the stores,
> you can only sell 10 rakes. The approach that is taken
> is quite nice, by simulating the notion of having a
> document per each of the rakes in the store and allowing
> users to place them in their cart.
In other words there are 10 documents in Mongo, not 1 document with a `"quantity": 10` attribute.
Then it would be difficult to add a reference to a specific items somewhere else (or one would even have to duplicate the data). The benefits and disadvantages of normalization vs denormalization are long known and this (denormalization) is possible with classic SQL DBMS too.
Comments
From the article:
In other words there are 10 documents in Mongo, not 1 document with a `"quantity": 10` attribute.Imagine that every of your items in a warehouse has a unique barcode to track it. In this case you have to keep a record in a database for every item.
And with current amounts of RAM on servers there would be no problems even if you have tens of millions of items.
Imagine that every of your items in a warehouse has a unique barcode to track it. In this case you have to keep a record in a database for every item.
You could have a list inside a single document.
And what about tracking item status and location? Another list?
Lists can contain items with complex structures, not just strings.
Then it would be difficult to add a reference to a specific items somewhere else (or one would even have to duplicate the data). The benefits and disadvantages of normalization vs denormalization are long known and this (denormalization) is possible with classic SQL DBMS too.