Thanks for the clarification and comments. I should reiterate that
for our project, we do *not* need to actually implement materialized
views, but only suggest refactoring and/or new components required to
implement them. I think implementing it would too time consuming for
a group of three students in one term, but we can definitely post our
findings here. We may also have some interesting MySQL source
architecture visualizations to show.
To make things a bit simpler, we've decided not to consider the query
optimizer or scheduling updates. Instead, we'll focus on the storage
engine and adding the keyword.
My understanding of materialized views for the purposes of our
assignment is that it's a view that caches the data when queried. If
the data changes, the cache will have to be recomputed (or at least
On 10/19/05, SGreen@stripped <SGreen@stripped> wrote:
> Just like Jigal, I also had to lookup the term "materialized view". For the
> sake of others on the list trying to follow along: a materialized view is
> basically a self-updating snapshot of a table (or tables) usually containing
> some sort of intermediate statistical computations involving GROUP BY.
> For instance, if you have the raw log of visitors to your web site stored in
> your database and you frequently ran queries that created summarations by
> day, you could save yourself a lot of processing time by periodically
> precomputing a "daily table" from your raw logs showing various statistics
> broken down for each date. Well, a materialized view would be one way to
> implement that "daily table".