SQL server 视图使用

view日常使用场景

场景一：
有的时候，多个表并表条件查询，尤其是好几张表那种一起查询的那种，结果集来自“五湖四海”，也看不出那张表更“主要”一些，即使可能写出来对应的SQL那也是相当的痛苦，各种select包一层select套了好几层，不说维护理解，就是修改起来也很难受，感觉本来改了一个地方，突然发现结果集又有别的问题，就是那种按起了葫芦有起了瓢那种，处处都能给你带来“惊喜”。

场景二：
主体大多数字段大概来自一张表，但是关联好几个表，这也没什么，这时候业务同学会跟你谈，要加很多限制，比如说某个类型订单我们只要从某个时间段的，我们查找范围要限制在什么几个状态下的几种类型。这种如果是确定一个功能，经常会用的话，尽量单独拿出来维护。

这时候不管是多表视图还是单表视图都可能解决一些问题。

视图是什么，有啥优缺点？

视图咱不咬文嚼字也不去别的博客那边去拷贝复制，用大白话来解释，他其实可以看作一个表，一个“虚”表。“虚”到什么程度，别看他也有字段，但是它实际并没有储存字段数据，他的数据更多是来自组成他的其他的表（这些表也可以说是这个视图的基表）来存储的，微信公众号：我是坑货，徒有一个类似表的数据结构。

但从我们使用，甚至创建语句都和表非常相似，既然和我们之前使用的表差不多，他到底有啥过人之处呢？

视图的优点

使用视图可以定制化一些数据，限制范围，过滤条件，从这个视图得到的数据因为都限制过滤定制化处理了，方便你去分析

聚合函数，多个表连接展示

合并分离的数据，分区试图
这个我要多说一下，类似于多个表并称成一个表。类似于三国赤壁里面的铁索连舟，主要特征是里面的关键词union。
尤其是很多表因为设计的问题，尤其是实际上很多结构相似表，比如说有的系统租聘订单，赠品单，销售订单虽然意义不同，但是里面很多字段差不多都是一个意思，比如交易时间，订单编号，交易客户等。但是呢，也有各自的比较有特色独有的字段，比如租聘的时间长短，赠品关联的订单等一大堆多余出来的字段，其实也可以会根据需求在视图展示出来。

保证数据安全
这个涉及到视图到底能不能修改和怎么修改，限制是什么后面我会单独讲。

视图的缺点

首先视图是一个虚表，很多在表上性能优化的手法可能就没有，而且数据库引擎要构建视图有一个过程，类似一个查询，视图的性能以及优化你就不要又太高的要求。你可以把他看作一个查询，而不是一个表真的优化也最好基于查询的优化来优化可能好一些。

修改限制
视图不好修改，我建议最好别对视图修改，有什么问题最好还是对组成视图的基表来操作，而且有的视图在某些数据库或者某些条件下是不能修改的。微信公众号：我是坑货

视图能不能修改
这个问题其实没什么，但是很多博客抄来抄去，只提了一嘴“某些条件下”不能修改，到底是什么情况“才是某些条件呢”？甚至有的直接说不能，实际上是不严谨的。

首先视图是可以改的，但是在某些条件下是不能做某些更新操作，实际情况我整理搜集的如下：

l可以在简单视图中执行DML 操作
l当视图定义中包含以下元素之一时不能使用delete:
•组函数
•GROUPBY子句
•DISTINCT 关键字
ROWNUM 伪列


当视图定义中包含以下元素之一时不能使用update :

l组函数
lGROUP BY子句
lDISTINCT 关键字
lROWNUM 伪列
l列的定义为表达式

当视图定义中包含以下元素之一时不能使用insert :

l组函数
lGROUP BY 子句
lDISTINCT 关键字
lROWNUM 伪列
l列的定义为表达式
l表中非空的列在视图定义中未包括