1.视图
视图是一个虚拟表,其内容由查询定义。同真实的表一样,视图包含一系列带有名称的列和行数据。
视图的数据变化会影响到基表,基表的数据变化也会影响到视图。
基本使用
创建视图
create view 视图名 as select语句;
案例
create view v_ename_dname as select ename, dname from EMP, DEPT where EMP.deptno=DEPT.deptno;
select * from v_ename_dname order by dname;
+--------+------------+
| ename | dname |
+--------+------------+
| CLARK | ACCOUNTING |
| KING | ACCOUNTING |
| MILLER | ACCOUNTING |
| SMITH | RESEARCH |
| JONES | RESEARCH |
| SCOTT | RESEARCH |
| ADAMS | RESEARCH |
| FORD | RESEARCH |
| ALLEN | SALES |
| WARD | SALES |
| MARTIN | SALES |
| BLAKE | SALES |
| TURNER | SALES |
| JAMES | SALES |
+--------+------------+
修改了视图,对基表数据有影响
select emp.ename, dept.dname, dept.deptno from emp,dept where emp.deptno=dept.deptno order by dname;
update v_ename_dname set ename='TEST' where ename='CLARK';
select * from EMP where ename='CLARK';
select * from EMP where ename='TEST';
修改了基表,对视图有影响
mysql> update EMP set deptno=10 where ename='JAMES'; -- 修改基表
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from v_ename_dname where ename='JAMES';
+-------+----------+
| ename | dname |
+-------+----------+
| JAMES | RESEARCH | <== 视图中的数据也发生了变化
+-------+----------+
删除视图
drop view 视图名;
视图规则和限制
与表一样,必须唯一命名(不能出现同名视图或表名)
创建视图数目无限制,但要考虑复杂查询创建为视图之后的性能影响
视图不能添加索引,也不能有关联的触发器或者默认值
视图可以提高安全性,必须具有足够的访问权限
order by可以用在视图中,但是如果从该视图检索数据中的order by将被覆盖
视图可以和表一起使用
实战OJ
牛客:针对actor表创建视图actor_name_view
2.MySQL中的视图
View是一种虚拟表,其内容由查询定义。同真实表(物理表)一样,视图包含行和列,但视图本身不包含数据。它是从一个或多个真实表中检索数据的SQL语句。当查询视图时,系统会根据定义视图的SQL语句来动态生成数据。
理解视图的关键点:
虚拟性:视图不是数据库中存储的数据集合,而是存储在数据库中的SQL查询语句。当对视图进行查询时,数据库会执行这些查询语句并返回结果。
安全性:视图可以限制用户对数据的访问,只显示给用户他们应该看到的数据。例如,可以创建一个只包含员工姓名和职位的视图,而不包含薪资信息,以保护敏感数据。
逻辑数据独立性:当真实表的结构发生变化时(如添加、删除或修改列),只要视图的查询语句仍然有效,视图的结构就不会受到影响。这有助于在数据库结构变化时维护应用程序的稳定性。
简化复杂查询:视图可以封装复杂的SQL查询,使得用户能够像查询简单表一样查询复杂的数据。这对于经常需要执行复杂查询的应用程序来说非常有用。
更新限制:虽然可以像查询表一样查询视图,但并非所有视图都支持更新操作(如INSERT、UPDATE、DELETE)。视图的更新能力取决于其定义方式以及底层表是否允许更新。
使用视图的场景:
数据抽象:隐藏复杂的SQL查询,只展示用户需要看到的数据。
数据安全性:限制对数据的访问,确保用户只能看到他们被授权的数据。
逻辑数据组织:将相关数据组合在一起,即使它们存储在多个表中。
报表和数据分析:为复杂的数据分析提供简单的查询接口。
注意事项:
当对视图进行更新操作时,必须确保这些操作在底层表上也是有效的,并且不会导致数据不一致。
视图可以提高查询效率,但也可能导致性能下降,特别是当视图基于复杂的查询或包含大量数据时。
视图可以嵌套,即一个视图可以基于另一个视图定义,但过深的嵌套可能会导致查询难以理解和维护。
3.视图中的order by
在MySQL中,视图(View)本身并不直接存储数据,而是存储了一个SQL查询语句。这个查询语句定义了如何从基础表(或其他视图)中检索数据来“呈现”视图的内容。因此,当你尝试在视图中直接使用ORDER BY子句时,实际上是在定义这个查询语句时包含了排序逻辑。
然而,有一个重要的点需要注意:当你在视图定义中包含ORDER BY子句时,这个排序逻辑可能并不会像你预期的那样工作。原因在于,当你从视图中检索数据时,除非你在外部查询中也明确指定了ORDER BY,否则视图中定义的ORDER BY可能不会生效。
这是因为,当MySQL执行视图查询时,它首先会执行视图定义中的查询(包括任何内部的ORDER BY),但这只是为了生成视图的内容。然后,当你从视图中检索数据时,MySQL会执行一个外部查询来“读取”视图的内容。如果这个外部查询没有自己的ORDER BY子句,那么最终的结果集可能不会按照视图内部定义的顺序来排序。
举个例子:
CREATE VIEW my_view AS
SELECT id, name, age
FROM users
ORDER BY age DESC;
-- 当你这样查询视图时:
SELECT * FROM my_view;
-- 结果可能不会按照age降序排列,除非MySQL优化器决定保留这个顺序(但这通常不是可依赖的行为)。
-- 为了确保结果按预期排序,你应该在外部查询中也指定ORDER BY:
SELECT * FROM my_view ORDER BY age DESC;
order by可以用在视图中,但是如果从该视图检索数据中的order by将被覆盖。
因此,虽然你可以在视图定义中包含ORDER BY子句,但最好将其视为视图定义的一部分,而不是最终查询结果的强制排序。如果你希望确保从视图中检索的数据是排序的,你应该在查询视图时明确指定ORDER BY子句。
另外,值得注意的是,在某些数据库系统中(虽然MySQL不是这种情况),视图定义中的ORDER BY可能会被视为语法错误或不被支持,因为视图通常被认为是数据的一个逻辑子集,而不是具有特定顺序的数据集。然而,在MySQL中,虽然可以在视图定义中包含ORDER BY,但它通常不会影响最终的查询结果,除非你在查询视图时也明确指定了排序逻辑。