[nine_k]

Caches are fleeting. Databases are durable. This is one distinction. Caches return a value by association. Databases usually allow for range and aggregate operations on many values. This is another distinction.

Also, "no-SQL databases" is like "non-green colors"; it encompasses a much larger spectrum than it excludes. Putting graph databases, local KV stores, distributed KV stores, document stores, time-series stores, etc in the same basket just because they are not RDBMSes is not very productive.

[tshaddox]

Is there a term for derived denormalized data that is stored separately for very fast retrieval (so far that’s basically the definition of “cache”) and must exist for the software to function? That last part makes it distinct from (or at least a special case of) a cache. This comes up all the time in application design. A basic example would be an activity feed in a social networking app. You probably want to show all recent events which are stored in many different tables, e.g. posts, comments, likes, friend requests, etc. but you probably also need to denormalize that data because a big SQL union or join across every table that represents an event is probably not possible to do on demand.

[solipsism]

It's called a materialized view.

[tshaddox]

That’s one implementation of a similar idea in RDBMSs, although they generally require manually refreshing them when desired. I think I’ve heard that some RDBMSs also allow you to apply normal inserts and updates to materialized views if you want to manually keep them up to date as well, although I’ve never tried that approach.

[vaughan]

It’s called incremental view maintenance.

Check out: https://wiki.postgresql.org/wiki/Incremental_View_Maintenanc...

[solipsism]

Manually refreshing them? How could such a process possibly be manual but not automatable? Does it involve turning a crank?