4 ms·

A materialized view is absolutely demoralized. The only distinction between something like a materialized view, an index, and just ad hoc representation of the

A materialized view is absolutely demoralized. The only distinction between something like a materialized view, an index, and just ad hoc representation of the same data in multiple places is that with an index and materialized view, it's explicitly considered to be a read only reflection of some underlying data, whereas some other structure is more likely to have common pitfalls such as not properly having a single source of truth.

taeric 3y ago
I love the typo of demoralized. :D But, yeah. My question for the thread is if that is considered in this case or not? I'm assuming the poorly done denormalizations are of the editable kind?
- antonvs 3y ago
  Depends what you mean by editable. Even though a materialized view may not be editable, many of its underlying values may be, and that's the root cause of the problem with denormalization. Denormalized data effectively involves caching some source value in a durable way. As the saying tells us, cache invalidation is one of the two hard problems in computer science. Of course in the denormalized DB context, detecting invalidation is typically simple: it's assumed to occur as soon as an update of a denormalized value occurs somewhere. At that point you may need an ACID update of all "cached" values, which is conceptually and computationally expensive. In the materialized view case, you may not do an update, but then you have an out of date cache. So, we do see the effects of denormalization in a materialized view, but the pros and cons are a little different than in the case where data is stored in a primary table.
  - taeric 3y ago
    I mean editable in the view. That you may have to cascade an edit out, makes sense. But, that fits how things are physically, too. Any store that puts prices on items will have a similar physical constraint that they are under.
- Izkata 3y ago
  Y'know, a materialized view has to be updated regularly... Could we call an out-of-date one demoralized, like, lost confidence?

taeric 3y ago

I love the typo of demoralized. :D But, yeah. My question for the thread is if that is considered in this case or not? I'm assuming the poorly done denormalizations are of the editable kind?

antonvs 3y ago
Depends what you mean by editable. Even though a materialized view may not be editable, many of its underlying values may be, and that's the root cause of the problem with denormalization. Denormalized data effectively involves caching some source value in a durable way. As the saying tells us, cache invalidation is one of the two hard problems in computer science. Of course in the denormalized DB context, detecting invalidation is typically simple: it's assumed to occur as soon as an update of a denormalized value occurs somewhere. At that point you may need an ACID update of all "cached" values, which is conceptually and computationally expensive. In the materialized view case, you may not do an update, but then you have an out of date cache. So, we do see the effects of denormalization in a materialized view, but the pros and cons are a little different than in the case where data is stored in a primary table.
- taeric 3y ago
  I mean editable in the view. That you may have to cascade an edit out, makes sense. But, that fits how things are physically, too. Any store that puts prices on items will have a similar physical constraint that they are under.
Izkata 3y ago
Y'know, a materialized view has to be updated regularly... Could we call an out-of-date one demoralized, like, lost confidence?