mysql 视图
一、使用视图的理由是什么?
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更倾向于选择合并方式。是因为它更加有效。