4 ms·

I added something about materialization while you replied. Materialization is controlled automatic denormalization. I would guess it is usually not labeled as d

I added something about materialization while you replied. Materialization is controlled automatic denormalization. I would guess it is usually not labeled as denormalization because the materialized data is not really part of your data model, it is more a cache of precomputed data that is automatically kept up to date and consistent. In contrast denormalization in the data model proper usually means that the code has to ensure that things remain consistent.

taeric 3y ago
I got confused, as I thought you meant you edited the linked article. :D So, yeah, this all makes sense. My assertion for it being more like reality was not that all data is denormalized. 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. That said, it sounds like we agree?
- 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 ago
    I 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.

taeric 3y ago

I got confused, as I thought you meant you edited the linked article. :D So, yeah, this all makes sense. My assertion for it being more like reality was not that all data is denormalized. 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. That said, it sounds like we agree?

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 ago
  I 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.