3 ms·
But if you have things like "color" or "configuration" of item normalized out so that the "shopping cart" is purely product ID listings, than that is just as in
by danbruc 3y ago
But if you have things like "color" or "configuration" of item normalized out so that the "shopping cart" is purely product ID listings, than that is just as inaccurate in other ways.
Here I would disagree. Normalization can not become inaccurate, you just keep getting rid of more and more redundancies the further you push your normalization efforts. If you have a product with different color options, then you probably need a two level model, one for the product and one for its variants. If you are selling computers and allow configuring them, it might become quite complex with different options for different aspects, there might be constraints like incompatible options or options that require others, the price might depend non-trivially on the different choices and so on. So in practice the complexity of really normalizing everything and then piecing everything back together in code is probably what will eventually stop you from going after the very last redundancies.
- taeric 3y agoI don't want us to just hash over silly examples that are easy to nitpick. My point is that if you have an inventory, you don't have normalized items. You have "realized" items that have, in fact, copied out the colors and other design choices out in a way that cannot cascade on edit. Stated differently, if the data can always cascade out with editing, than yeah, it should probably be normalized. If it is a design choice that gets fixed on application, it can be argued that it should be copied out when it can't be changed.