关于范式和联合查询之间的矛盾各位有什么高招？

索引视图显著提高了某些类型查询的性能。说明  只有安装了 Microsoft® SQL Server™ 2000 企业版或 Microsoft SQL Server 2000 开发版，才可以创建索引视图。
如果很少更新基础数据，则索引视图的效果最佳。索引视图的维护可能比维护表索引的成本高。如果经常更新基础数据，则维护索引视图数据的成本可能超过使用索引视图所带来的性能收益。索引视图提高下列查询类型的性能： 处理大量行的联接和聚合。
许多查询经常执行的联接和聚合操作。 
例如，在联机事务处理 (OLTP) 数据库记录清单中，许多查询都希望联接 Parts、PartSupplier 和 Suppliers 表。虽然每个执行此联接的查询需要处理的行可能并不多，但若将成百上千这样的查询联接起来，则总的处理量将非常大。因为这些关系不大可能经常更新，可定义一个索引视图来存储联接结果，以提高整个系统的总体性能。决策支持工作负荷。 
分析系统的特点是存储不经常更新的、汇总的聚合数据。而许多决策支持查询的特点是进一步聚合数据并联接大量行。索引视图通常不会提高下列查询类型的性能： 具有大量写操作的 OLTP 系统。
具有大量更新操作的数据库。
不涉及聚合或联接的查询。
具有键的高基数度的数据聚合。高基数度表示键包含许多不同的值。唯一键具有可能的最高基数度，因为每个键具有不同的值。索引视图通过减少查询必须访问的行数来提高性能。如果视图结果集的行数与基表的行数差不多，则使用视图获得的性能收益微乎其微。例如，请看以下对一个有 1,000 行的表的查询： 
SELECT PriKey, SUM(SalesCol)
FROM ExampleTable
GROUP BY PriKey如果表键的基数是 100，那么使用该查询结果生成的索引视图将只有 100 行。使用视图的查询所需的平均读取量是在基表上进行读取的十分之一。如果键是唯一键，则键的基数是 1000 且视图结果集返回 1000 行。这种使用索引视图而不是直接读取基表的查询方式，在性能方面没有任何收益。扩充联接，即结果集大于基表中原始数据的视图。 
索引视图与查询相结合
虽然对可索引的视图的限制可能使您无法设计解决全部问题的视图，但仍可以设计多个较小的索引视图以加快部分进程的速度。 请考虑下列示例： 假设某个经常执行的查询不仅要聚合某一数据库中的数据，还要聚合另一数据库中的数据，并且要联接结果。因为索引视图不能从多个数据库中引用表，所以不能设计单个视图来完成整个过程。但是，可在每个数据库中创建一个为该数据库执行聚合的索引视图。如果优化器可将这些索引视图与现有查询匹配，由于无须对现有查询重新编码，至少会加快聚合处理的速度。虽然联接处理速度没有加快，但因为使用存储在索引视图中的聚合，所以总体查询速度将更快。
假设某个经常执行的查询要聚合几个表中的数据，然后使用 UNION 组合结果。一个索引视图中不允许使用 UNION。可再设计一些视图以执行各个聚合操作。这样一来，优化器就可以选择索引视图以加快查询的速度而无须对查询重新编码。尽管 UNION 处理速度没有提高，但每一个聚合进程的速度确实提高了。 
设计可满足多个操作的索引视图。因为优化器可使用即使没有在 FROM 子句中指定的索引视图，所以，设计良好的索引视图可加快许多查询的处理速度。例如，考虑在以下视图上创建索引：CREATE VIEW ExampleView (PriKey, SumColx, CountColx)
AS
SELECT PriKey, SUM(Colx), COUNT_BIG(Colx)
FROM MyTable
GROUP BY PriKey该视图不仅能满足直接引用视图列的查询，还可用于满足查询基表并包含表达式如 SUM(Colx)、COUNT_BIG(Colx)、COUNT(Colx) 和 AVG(Colx) 的查询。因为所有这些查询只须在视图中检索少量的行而不需要从基表中读取全部行，所以查询速度将更快。