（转摘）_《数据库设计入门经典》:构建快速执行的数据库模型_8.5 使用视图

8.5  使用视图
与流行的观念相反，视图实际上有损于性能——不一定是因为使用视图，而是由于视图在商业环境中的常见用法。那么在数据库模型设计阶段，为什么不将视图作为性能调整的工具呢？本书将从数据库建模的角度进行解释。
提示：
视图并不等同于物化视图。视图创建逻辑覆盖时并不会从表中复制数据。查询视图相当于直接查询底层表。物化视图则是数据的物理副本。查询物化视图时会查询物化视图本身，而不会查询底层表。
因此视图对性能没有提高。也就是说，这样会使应用程序的运行更为缓慢。作为本书作者，我必须让您知道我并非对视图有所偏见。那么我如何能说服您呢？首先要说，数据库管理员和应用程序开发人员的工作我都做过。这表示我曾从软件开发(开发人员)的角度和维护现有软件(管理员)的角度来使用视图。
管理员常用视图来实现记录与字段级别的安全性。换言之，使用视图可以限制特定用户只能访问表中特定记录。这是因为视图中包含查询，该查询可以使用WHERE子句筛选，从而限制了从底层表返回的记录。
CREATE VIEW BooksStartingWithA AS SELECT * FROM EDITION WHERE TITLE LIKE 'A%';
查询该视图时会返回标题以字母A开头的图书。下面的查询则限制表中字段的访问，而不是限制对记录的访问：
CREATE VIEW BooksWithoutRankings AS SELECT SBN,PUBLISHER_ID,PUBLICATION_ID
    ,PRINT_DATE,PAGES,LIST_PRICE,FORMAT FROM EDITION WHERE TITLE LIKE 'A%';
视图从如图8-2所示的表中检索记录。
                                  

                                                  图8-2  使用视图限制访问
访问RANK字段和INGRAM_UNITS字段的唯一方法是使用如下查询直接访问该表：
SELECT * FROM EDITION;
很明显，如果不希望某些用户访问RANK字段和INGRAM_UNITS字段，那么可以限制表的访问而只允许访问视图。这样终端用户就只能访问该视图。
不同的用户对访问的安全性要求也不同。终端用户只会在视图中访问专门为他们准备的数据；因此，在某个表中执行经理能看到所有字段及所有记录，而非管理层员工就无法看到(例如员工薪水)。让员工看到彼此的薪水是会降低士气的。同样，管理人员访问的信息也可能不同，比如需要实际业务信息，而不要求技术细节。
视图的问题在于开发人员或管理员常用视图来简化应用程序编码，从而导致系统变慢。所以，使用视图绝对没有问题，实际问题是经常不正确地使用视图。这个原因非常重要。绝对不能假设访问数据库的每一个人都样样精通，就算数据库模型设计人员自己也不例外。这么来说，执行经理使用数据仓库报表时，他们对数据库内部机制的了解程度就相当于您对行政管理的了解——完全不懂！
虽然视图是逻辑覆盖，不过也是数据库对象。如果在数据库中使用视图，那么视图实际上会成为数据库模型的一部分，因为视图会分解数据，即使只是逻辑分解而非物理分解。考虑视图和数据库模型性能时，要注意视图的使用。开发人员和一般用户群对视图的使用越多，对这些视图的监视和性能调整就越多。视图的管理就可能会越来越麻烦，因此最终将无法解决性能问题。
提示：
以我20年的开发经验和数据库管理经验来说，我发现避免滥用视图、误用视图和乱用视图的最好方法是完全不使用视图。当然这仅仅是我个人观点，并非绝对。
谨慎使用视图。视图具有非常特殊的作用，误用视图也是最危险的。
下面将讨论另一个有趣的主题：应用程序缓存。