视图检索运算的替换过程与"物化"实现违反主旨

针对视图的只读（检索）运算，DBMS的实现原理靠”替换”（substitution）过程完成： 先用视图的定义表达式直接替换查询里对视图名称的引用（比如把FROM LS替换成 FROM(SELECT S.* FROM S WHERE S.CITY='London') AS LS），得到的表达式再交给 系统直接计算或进一步简化（简化通常是出于性能考虑）。这个过程之所以总能成立， 根源正是[[关系代数的闭包性质]]：闭包意味着任何能用变量名代表值的地方，都能 用一个更一般的、类型正确的表达式来替代这个名字——FROM子句既能接受表名也能 接受表表达式，这正是替换合法的理论依据；视图本身还可以进一步在其他视图上 定义（视图之上再建视图），只要最终一路替换到底层基关系变量即可。这个机制 在SQL早期版本（1992年之前）曾因为标准本身没有完全支持闭包性质而经常失败—— 比如对一个内含GROUP BY聚合的视图V做WHERE过滤，直接替换后会生成 WHERE SUM(STATUS)>25 GROUP BY CITY这种把聚集函数直接放进WHERE子句的非法 语法，导致一个看起来完全平常的查询以令人费解的方式编译失败。标准后来修正 了这个问题，但书中特别指出：至少还有一个主流SQL产品至今没有跟进标准的替换 机制，而是转而采用”物化”（materialization）方式实现视图查询——先真的计算 视图定义表达式、把结果构建成一张实体表，再针对这张物化后的表执行用户请求 的查询。这种实现方式看似满足了关系模型对结果的表面要求，但书中明确认为它 背离了关系模型的主旨（呼应[[基关系与视图在关系模型中没有本质物理差异]]里 “视图本不该被物化”的立场），而且性能表现也未必理想。