数据库综合系列之视图

浏览： ℃

字体：大中小

发布时间：2013-12-20 16:18:32

来源：

视图可以看作定义在SQL Server上的虚拟表.常规视图本身并不存储实际的数据，而仅仅存储一个Select语句和所涉及表的metadata.

对数据操作建立在之前建立的表基础上：

具体见http://blog.csdn.net/buyingfei8888/article/details/17399837

为什么要使用视图(View)

从而我们不难发现，使用视图将会得到如下好处:

视图隐藏了底层的表结构，简化了数据访问操作

因为隐藏了底层的表结构，所以大大加强了安全性，用户只能看到视图提供的数据

使用视图，方便了权限管理，让用户对视图有权限而不是对底层表有权限进一步加强了安全性

视图提供了一个用户访问的接口，当底层表改变后，改变视图的语句来进行适应，使已经建立在这个视图上客户端程序不受影响

视图(View)的分类

视图在SQL中可以分为三类

1. 普通视图(Regular View)

2. 索引视图(Indexed View)

3. 分割视图(Partitioned View)

视图(View)的最佳实践

一定要将View中的Select语句性能调到最优（貌似是废话，不过真理都是废话…)

View最好不要嵌套，如果非要嵌套，最多只嵌套一层

能用存储过程和自定义函数替代View的，尽量不要使用View，存储过程会缓存执行计划，性能更优，限制更少在分割视图上，不要使用聚合函数，尤其是聚合函数还包含了Distinct在视图内，如果Where子句能加在视图内，不要加在视图外（因为调用视图会返回所有行，然后再筛选，性能杀手，如果你还加上了order by…..)

下面对三种视图的应用，主要是普通视图

1 普通视图

创建视图：
[sql] view plaincopyprint?01.create view shopSale
02.as
03.select s_name 商店名字,s_address 商店地址,c_name 销售人员 from t_shop,t_cash_housewoker where s_id in(select s_id from manage where m_id=1) and t_cash_housewoker.m_id=1
create view shopSale
as
select s_name 商店名字,s_address 商店地址,c_name 销售人员 from t_shop,t_cash_housewoker where s_id in(select s_id from manage where m_id=1) and t_cash_housewoker.m_id=1
使用：
[sql] view plaincopyprint?01.select * from shopSale
select * from shopSale2 索引视图

其实索引视图也很类似，在普通的视图的基础上，为视图建立唯一聚集索引，这时这个视图就变成了索引视图.

索引视图可以看作是一个和表(Table)等效的对象！

聚集索引简单来说理解成主键，数据库中中的数据按照主键的顺序物理存储在表中，就像新华字典，默认是按照ABCD….这样的方式进行内容设置。ABCD….就相当于主键.这样就避免了整表扫描从而提高了性能.因此一个表中只能有一个聚集索引。

为一个视图加上了聚集索引后。索引视图会将数据物理存在数据库中，索引视图所存的数据和索引视图中所涉及的底层表保持同步。

理解了索引视图的原理之后，我们可以看出，索引视图对于OLAP这种大量数据分析和查询来说，性能将会得到大幅提升。尤其是索引视图中有聚合函数，涉及大量高成本的JOIN,因为聚合函数计算的结果物理存入索引视图，所以当面对大量数据使用到了索引视图之后，并不必要每次都进行聚合运算，这无疑会大大提升性能.

而同时，每次索引视图所涉及的表进行Update,Insert,Delete操作之后，SQL Server都需要标识出改变的行，让索引视图进行数据同步.所以OLTP这类增删改很多的业务，数据库需要做大量的同步操作，这会降低性能。

谈完了索引视图的基本原理和好处与坏处之后，来看看在SQL Server中的实现:

在SQL Server中实现索引视图是一件非常，简单的事，只需要在现有的视图上加上唯一聚集索引

但SQL Server对于索引视图的限制却使很多DBA对其并不青睐:

比如:

索引视图涉及的基本表必须ANSI_NULLS设置为ON

索引视图必须设置ANSI_NULLS和QUOTED_INDETIFIER为ON