When logic programming meets CQRS
Liron Shapira

Materialized views only work for basic data transformations. They aren’t smart enough to incrementally update themselves in reaction to write-model operations. Plus their consistency guarantees are weak.

SQL Server offers a good implementation with consistency guarantees that does exactly this, no? SQL Server calls them indexed views.

With SQL Server you can define a view that encapsulates the query or aggregation logic you want — which is equivalent to Eve’s bind — and then by asking SQL Server to index the view, it will automatically take care of updating that view so that queries against the view just pull pre-computed results. The cost is paid on the write side, since a write to any source table triggers an automatic update to any downstream indexed views that reference them. And from what I’m reading, it looks like SQL Server knows how to incrementally update the indexed view based on what changed upstream, but I’m not 100% sure about that.

There are several restrictions on what an indexed view can do, so they are definitely not a general solution for building arbitrary graphs of data relationships. But you can use them today (and they’ve been around since 2008, at least) to build, for example, an account balance table that automatically updates from a log of transactions.