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 invalidated). -Andrew On 10/19/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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". -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
