物化视图，索引，数据仓库

http://www.os2ora.com/materialized-view-index-data-warehousing/

Materialized Views, 其实不是View。我觉得把它归类于Index可能还准确一些。

View在我们的印象里总是逻辑存在的。即使前面加上一个Materialized，我们只会觉得奇怪，干嘛要对View进行物化呢？

把它理解为一种特殊的Index未尝不可，况且，它与Index有一些相同点：

They consume storage space.

They must be refreshed when the data in their master tables changes.

They improve the performance of SQL execution when they are used for query rewrites.

Their existence is transparent to SQL applications and users.

而一般的View呢？

They don’t consume storage space.

They don’t need to be refreshed when the data in their master tables changes.

They don’t improve the performance of SQL execution, database just maps the View to the underlying Table when executing.

Their existence is transparent to SQL applications and users.

不过，Materialized View为什么特殊，我觉得在于它的应用场合——数据仓库。或许我们可以说，Materialized View 是专门用于数据仓库的Index。

问题在于，数据仓库场合和OLTP场合对Index的要求有哪些不同，干嘛需要一个专门的Materialized View？

数据仓库的查询一般都是”大”查询。何谓大？多表联合（n个大表join在一起），多维度分析（一长串的group by），聚合统计（avg, count, sum,rank,cube）。

数据库如何跑这种查询呢？硬件方面，用更多的CPU和硬盘；软件方面，采用数据分区，并行执行。软硬件一起提供的厂商，如Oracle的Exadata, Teradata, Netezza, 可能做到数据库软件与硬件的紧密结合，从而实现对数据的智能扫描（在IO这一层实现对不需要数据的过滤）等技术。

这种做法可以很好地应对数据仓库里一类重要的查询：随机查询。例如，某位领导突然想到了一个决策方案，开发人员必须为这种决策提供分析数据。

另一方面，如果某类“大”查询经常被执行，我们就得想办法对其进行优化了。最直接的方法就是缓存中间结果，多表连接的结果，多维度分析的结果，聚合统计的结果，对了，这就是Materialized View的用武之地了。

Materialized View缓存了中间结果，Oracle通过Query Rewrite的技术把对基表的访问转换成对Materialized View的访问。这个对性能的提高可以是成千上万倍的。

如何创建Materialized View以便让Query Rewrite用到，这也许是Materialized View里面最重要的部分，也是理解Query Rewrite如何工作的一个途径。最好的参考文献当然是Oracle的Oracle® Database Data Warehousing Guide.

以后的文章再回来看看Query Rewrite的实现。