> 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.
A products table with a document per product. A user table. An order table with line items in an array of embedded objects.
One would subtract product from amout field in products table to set new inventory level. A new order document gets created with all information needed to describe an order. Fields like total, subtotal, date would sit at the root level and line items with product descriptions and prices would be embedded as an array of objects. Then a user object with user_id, name address would be embedded.
Dealing with documents is a different but being able to contain the entire dataset with some relations is nice.
