5 ms·
Did I read that right? A document per item in inventory? This seems horribly inefficient.
by bsg75 9y ago
Did I read that right? A document per item in inventory? This seems horribly inefficient.
- lilbobbytables 9y agoAs someone not versed in Mongo or anything similar, what is the alternative? A large array of docs that has to be loaded in to memory to work with?
- pjungwir 9y agoFrom the article: > 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.
- codedokode 9y agoImagine 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.
- icebraining 9y agoImagine 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.
- codedokode 9y agoAnd what about tracking item status and location? Another list?
- icebraining 9y agoLists can contain items with complex structures, not just strings.
- codedokode 9y agoThen 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.
- wolco 9y agoA 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.
- mrlinx 9y agoWhat else would you suggest?
- bildung 9y ago{"product":"rake", "in_stock":10}
- deleted 9y ago[deleted]
- paulddraper 9y agoWhat facilities are those at? What is their current status? We have a defect report; what is the case number?
- bildung 9y agoIf you want to use that in the real world, I'd say there is no way around a real relational database.
- BjoernKW 9y agoIt depends. If you use the event sourcing design pattern and CQRS this can be very efficient, especially if you have huge number of purchase and sale events.