OS与Oracle

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…….

对上一篇文章里提到两条语句
select distinct begin_date, end_date, begin_date + level -1 day from test connect by begin_date + level -1 <= end_date order by 1,2,3;
和
select one_date
from (select start_date + level – 1 one_date
from (select min(start_date) start_date, max(end_date) end_date
from test) test
connect by start_date + level – 1 < = end_date ) all_date,
test
where one_date between start_date and end_date;

它们都实现相同的功能，即: 当一个表里面有两个列，分别为begin_date和end_date时，如何针对这个表的每一行，用SQL返回begin_date和end_date之间的所有连续日期。

这两条语句的可扩展性问题是下面是讨论的重点……

举个例子，假设有两个日期 2009-03-20和2009-03-23，如果用SQL返回2009-03-20, 2009-03-21, 2009-03-22, 2009-03-23。 更一般的，当一个表里面有两个列，分别为begin_date和end_date时，如何针对这个表的每一行，用SQL返回begin_date和end_date之间的所有连续日期……

汇总统计是数据处理中常见的一个操作。对于一般的数据模型来说，一般是有一个事实表，若干个维度表，通过事实表与维度表的连接，实现不同层次的查询汇总。
问题是对于组织结构而言，一般所有的数据都存贮于一个表中，而且，组织结构的层次也是动态的。那么，在这种情况下，如何实现员工工资的汇总呢？一个比较有趣的问题是: 如何统计员工及其所有被管理员工的总工资，举个例子，CEO的总工资就是整个公司总有员工的总工资之和，包括他自己……

虽然Oracle不是一个层次型的数据库，不过它却对层次型应有不错的支持。
层次型应用最常见的是一个公司内部的组织结构。
在计算机科学中，或者更具体地说，在数据结构中，层次型结构是由“树”来描述的。节点之间的关系代表着上下两个层次之间节点的关系，即父子关系。这一般是一对多的关系。
一般地，我们会把这一系列的父子关系存贮到数据库里的一个表里面。
而Oracle的任务，就是要重现这棵树，并实现有关层次关系的运算……