一、使用视图的理由是什么？
1.安全性。一般是这样做的:创建一个视图，定义好该视图所操作的数据。之后将用户权限与视图绑定。这样的方式是使用到
了一个特性：grant语句可以针对视图进行授予权限。
2.查询性能提高。
3.有灵活性的功能需求后，需要改动表的结构而导致工作量比较大。那么可以使用虚拟表的形式达到少修改的效果。这是在
实际开发中比较有用的。
例子：假如因为某种需要，a表与b表需要进行合并起来组成一个新的表c。最后a表与b表都不会存在了。而由于原来程序中编
写sql分别是基于a表与b表查询的，这就意味着需要重新编写大量的sql(改成向c表去操作数据)。而通过视图就可以做到不修
改。定义两个视图名字还是原来的表名a和b。a、b视图完成从c表中取出内容。
说明：使用这样的解决方式，基于对视图的细节了解越详细越好。因为使用视图还是与使用表的语法上没区别。比如视图名a
，那么查询还是"select * from a"。
4.复杂的查询需求。可以进行问题分解，然后将创建多个视图获取数据。将视图联合起来就能得到需要的结果了。
视图的工作机制:当调用视图的时候，才会执行视图中的sql，进行取数据操作。视图的内容没有存储，而是在视图被引用的
时候才派生出数据。这样不会占用空间，由于是即时引用，视图的内容总是与真实表的内容是一致的。
视图这样设计有什么好处？节省空间，内容是总是一致的话，那么我们不需要维护视图的内容，维护好真实表的内容，就可
以保证视图的完整性了。
二、通过更新视图实现更新真实表
看到很多例子，更新视图可以更新真实表。原因，我是这样理解的：视图并没有保存内容。只是引用数据。那么，更新视图
，其实就是以引用的方式操作了真实表
with check option：对视图进行更新操作的时，需要检查更新后的值是否还是满足视图公式定义的条件。通俗点，就是所更
新的结果是否还会在视图中存在。如果更新后的值不在视图范围内，就不允许更新
如果创建视图的时候，没有加上with check option，更新视图中的某项数据的话，mysql并不会进行有效性检查。删掉了就
删掉了。在视图中将看不到了。
使用有效性检查，实际意义是什么？
视图的实践：重新组织表的需求
CREATE TABLE `result` (`MATH_NO` INT(10) NOT NULL unsigned AUTO_INCREMENT PRIMARY KEY,
`TEAMNO` INT(10) NOT NULL,
`PLAYERNO` INT(10) NOT NULL,
`WON` VARCHAR(10) NOT NULL,
`LOST` VARCAHR(10) NOT NULL,
`CAPTAIN` INT(10) NOT NULL COMMIT '就是PLAYERNO的另外名字',
`DIVISION` VARCHAR(10) NOT NULL
) ENGINE=MYISAM DEFAULT CHARSET=utf8 COMMIT='重新组的新表' AUTO_INCREMENT=1
针对每个表创建一个视图，将数据保存进去：
CREATE VIEW teams(TEAMNO,PLAYERNO,DIVISION) AS SELECT DISTINCT TEAMNO,CAPTAIN,DIVISION FROM result
报错：#1050 - Table 'teams' already exists
说明，因为视图也是一种表，是虚拟表。不能与已有的表(视图)出现重名
接下来，删掉表teams，再执行创建视图的代码。
将视图看成与表一样的东西，更加容易理解使用规则。下面这样对比也许使自己更好理解：
1.在使用视图的时候，就是与使用表的语法一样的。
2.创建视图的时候，该视图的名字如果与已经存在表重名的话，那么会报错，不允许创建。视图就是一种特殊的表
3.创建视图的时候，可以这样使用CREATE VIEW teams(TEAMNO,PLAYERNO,DIVISION)，可以定义视图表的结构。
4.在phpmyadmin中。左边的表列表中将视图与表列在了一起。只有通过右侧的状态"View:teams"可以知道该表是视图表。
视图在mysql中的内部管理机制:
视图的记录都保存在information_schema数据库中的一个叫views的表中。具体某个视图的定义代码以及属于哪个数据库等信
息可以从里面看到
理解视图的两种工作机制：
语句：select * from teams
针对上面语句，总结几个知识点
1.确认是视图的过程：teams也可以是表名。由于表与视图的物理机制不同。视图本身是不存储内容的。所以，在使用sql的
时候，mysql是怎么知道teams是一个视图还是表。是因为有一个查看目录的例程在做这件事。
2.mysql对处理视图的两种方法：替代方式和具体化方式。
替换方式理解，视图名直接使用视图的公式替换掉了。针对上面视图teams，mysql会使用该视图的公式进行替换，视图公式
合并到了select中。结果就是变成了如下sql语句：
select * from (SELECT DISTINCT TEAMNO,CAPTAIN,DIVISION FROM result)。
也就是最后提交给mysql处理该sql语句。
具体化方式理解，mysql先得到了视图执行的结果，该结果形成一个中间结果暂时存在内存中。之后，外面的select语句就调
用了这些中间结果(临时表)。
看起来都是要得到结果，形式上有区别，好像没体会到本质上的区别。两种方式又有什么样的不同呢？
替换方式，将视图公式替换后，当成一个整体sql进行处理了。具体化方式，先处理视图结果，后处理外面的查询需求。
替换方式可以总结为，先准备，后执行。
具体化方式总结理解为，分开处理。
哪种方式好？不知道。mysql会自己确定使用哪种方式进行处理的。自己在定义视图的时候也可以指定使用何种方式。像这样
使用：
CREATE ALGORITHM=merge VIEW teams as SELECT DISTINCT TEAMNO,CAPTAIN,DIVISION FROM result
ALGORITHM有三个参数分别是：merge、TEMPTABLE、UNDEFINED
看mysql手册中提到，替换与具体化的方式的各自适用之处，可以这样理解：
因为临时表中的数据不可更新。所以，如果使用参数是TEMPTABLE，无法进行更新。
当你的参数定义是UNDEFINED(没有定义ALGORITHM参数)。mysql更倾向于选择合并方式。是因为它更加有效。