I would call this one-row-per-contract-type, and this is the most general model for the problem (e.g. the model cannot be further broken down into finer level), thus, the most scalable model given storage is dirt cheap.
replyComes down to type of items, when you have physical inventory the number is limited so more manageable and interestingly enough the problem only applies to physical inventory.
replyYou are just spending some more disk space to avoid synchronization issues. Denormalization for performance is a really common pattern, just that people do not start with it in the first place itself
you should, their design is not the best. There is middle ground between "one row per SKU" and "1000 rows per SKU".
replyIts called one row per shopping cart*SKU combo.
if two people order 100 and 500 items of the same SKU, respectively, the table should have only two rows: for order1 and order2. Not 600 rows.
Can you explain how that works? With the row-per-item I can see how you’d use locking primitives etc easily to deal with multiple concurrent shopping carts claiming available inventory.. but how does your solution solve contention? There’d need to be some “number of items in inventory” row, wouldn’t there be contention on that?
replyThe point of one row per item is that thousands of concurrent shoppers don’t need to block each other as they can each claim as many free rows as they need for themselves?
explained below in https://news.ycombinator.com/item?id=49228432
replyI guess it depends on how the replenishment process works. Unless you're ordering over 1000 of an item, I doubt it would be a problem.
replyreplenishment is an unnecessary cludge that only exists due to poor design. an "algorithmical smell" if you wish
replyDepends on the scale. Most companies don't approach the scale where this matters.
reply