为什么80%的码农都做不了架构师？>>> 
一、使用视图的理由是什么？
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更倾向于选择合并方式。是因为它更加有效。