一、视图概述

在数据库管理系统中，视图（View）是一种虚拟表，它并不实际存储数据，而是基于一个或多个实际表的查询结果。视图提供了一种对数据库中数据进行抽象和封装的方式，用户可以按照自己的需求定义视图，并通过视图来操作和访问数据，而无需直接处理底层表结构的复杂性。

视图的主要特点：

1、逻辑表：视图是从一个或多个基本表（或者其它视图）导出的虚表，其内容由查询语句定义，不独立存储实际数据。
2、数据安全性：通过视图，数据库管理员可以控制用户对数据的访问权限，只让用户看到和修改他们需要的部分数据。
3、简化查询：视图可以隐藏复杂的查询逻辑，使得用户可以使用更简洁的方式来访问数据。
4、数据整合：从不同表中抽取相关的列组成视图，实现数据的逻辑整合。
5、数据更新限制：并非所有的视图都可以用于插入、更新和删除操作，这取决于视图的定义方式以及数据库系统的支持程度。

视图创建与使用示例：
以MySQL为例
假设我们基于上述示例，为employees和departments表创建基本的建表语句：

-- 创建员工表
CREATE TABLE employees (id INT PRIMARY KEY,name VARCHAR(100),department_id INT,salary DECIMAL(10, 2)
);-- 创建部门表
CREATE TABLE departments (id INT PRIMARY KEY,department_name VARCHAR(100)
);-- 插入一些示例数据
INSERT INTO departments (id, department_name) VALUES
(1, '销售部'),
(2, '技术部');INSERT INTO employees (id, name, department_id, salary) VALUES
(1, '张三', 1, 5000),
(2, '李四', 1, 6000),
(3, '王五', 2, 7000);

假设有一个员工表employees，包含id，name，department_id，salary等字段，还有一个部门表departments，包含id和department_name字段。为了方便员工查看自己所在部门的所有人员信息，我们可以创建一个视图：

CREATE VIEW employee_department AS
SELECT e.id, e.name, d.department_name, e.salary
FROM employees e
JOIN departments d ON e.department_id = d.id;

这样，用户就可以像查询真实表一样查询这个视图：

-- 查询销售部所有员工信息
SELECT * FROM employee_department WHERE department_name = '销售部';

需要注意的是，当基表中的数据发生变化时，通过视图查询到的结果也会随之变化，因为视图是动态反映其依赖的基础表的数据状态的。同时，如果视图允许更新操作，那么对视图的更新实际上会影响到对应的基表。

二、使用视图注意点

视图使用的一些注意点

在使用数据库视图时，需要注意以下几点，并通过例子来说明：
1、数据更新限制： 视图可以用于查询操作，但并非所有视图都支持插入、更新和删除（DML操作）。这主要取决于视图的定义。如果视图包含了GROUP BY、DISTINCT、JOIN或者UNION等聚合或复杂操作，可能无法直接进行修改。例如：

   -- 创建一个基于聚合函数的视图CREATE VIEW employee_avg_salary ASSELECT department_id, AVG(salary) as avg_salaryFROM employeesGROUP BY department_id;-- 尝试对这个视图进行更新，通常会失败，因为avg_salary是聚合函数的结果UPDATE employee_avg_salary SET avg_salary = 5000 WHERE department_id = 1;

2、权限管理： 虽然视图可以用来实现数据安全性，但要谨慎管理用户对视图的权限。如果不正确地分配了权限，可能会导致用户通过视图间接访问到原本不应查看的数据。例如：

   -- 假设有一个只显示部门A员工信息的视图CREATE VIEW department_A_employees ASSELECT * FROM employees WHERE department_id = 'A';-- 如果错误地赋予用户对这个视图的写权限，他们可能尝试更新实际表中的数据GRANT INSERT, UPDATE, DELETE ON department_A_employees TO user1;

3、性能影响： 视图的操作最终会转换为对底层表的操作，因此，复杂的视图查询可能会影响性能。特别是当视图涉及多个表的JOIN或者包含子查询时，执行效率可能较低。为了提高性能，应确保视图定义简洁且有效利用索引。
4、依赖性与刷新： 视图的内容依赖于其引用的基础表。一旦基础表的数据发生变化，通过视图查询得到的结果也会随之变化。但某些情况下，如物化视图，需要手动刷新才能获取最新的数据。
5、命名冲突： 在创建视图时，要注意避免与已存在的表或视图名称发生冲突，以防止混淆和误操作。
6、维护成本： 当基础表结构发生变化时，可能需要重新考虑并调整相关视图的定义，尤其是那些依赖于特定列名或字段顺序的视图。
7、嵌套视图： 使用嵌套视图（即视图中包含其他视图）可能导致查询更加复杂，增加理解难度，并可能影响性能。在设计时尽量减少视图的嵌套层级，保持结构清晰。

三、视图操作是否影响基本表

视图的操作在特定条件下可以影响基本表。具体来说：
1、查询操作：对视图进行SELECT查询不会直接影响基本表，它只是基于视图定义的查询语句从基本表中检索数据。
2、插入（INSERT）、更新（UPDATE）和删除（DELETE）操作：

• 在某些情况下，用户可以在视图上执行DML操作，并且这些操作会反映到相应的基表中。但是，这要求视图满足以下条件：

  • 视图必须是可更新视图，即视图中的每一行都能唯一映射回基表的一行。
  • 更新操作不能违反任何约束，如主键、外键或唯一性约束。
  • 不涉及分组函数、DISTINCT、JOIN等非确定性或复杂的表达式。

• 当在符合上述条件的视图上执行修改操作时，数据库系统会将这些修改转换成对基础表的相应操作。

3、不符合更新条件的情况：

• 如果视图不满足可更新条件，通常无法直接通过视图来更改底层表的数据，试图这样做可能会导致错误或者数据库系统拒绝执行该操作。总结而言，视图本身不存储数据，但针对部分允许更新的视图进行操作时，确实能够间接影响到关联的基本表。然而，对于那些设计为只读或结构复杂不支持更新的视图，则不会对基本表造成影响。

MySQL-视图：视图概述、使用视图注意点、视图是否影响基本表 到此完结，笔者归纳、创作不易，大佬们给个3连再起飞吧