数据库视图只是伪装成表的查询。
数据表主要记录数据。视图产生从该数据派生的信息。
下面是几个用途:
1、抽象
也许您必须连接来自数十个不同表的数据才能获得特定类型报告所需的所有数据。因此，您可以通过创建一个将所有数据拉到一起的视图来抽象掉这些细节，然后查询它，就好像所有数据都已经很好地存储在一起一样。
2、安全
您不想向人们提供比他们需要的更多的访问权限。通过创建视图并仅授予对视图而不是基础表的访问权限，用户将只能查询您在视图中专门选择的内容。
3、效率
如果您知道您的用户将不得不查询一个特定的数据域，这将需要多个不同的表以特定的方式全部连接在一起，那么（从开发的角度来看）更高效并且一致的是只有一个视图，他们可以全部使用。
话虽如此，在许多情况下，视图也很糟糕。
如果你正在处理非常大的表，视图会浪费大量的计算资源，因为查询优化器无法告诉视图“我们只需要今年的数据”，视图总是会加载整个结果存入内存。
在一个每个人都可以完全访问数据库、对表有百科全书式知识并可以快速编写查询的完美世界中，视图是不必要的并且计算效率低下。
一些具体用例：
- 每次需要特定数据时，使用视图比粘贴复杂查询更容易。更少的代码，更少的混乱，更少的混乱机会。如果许多用户需要相同的视图，则特别有用。
- 视图可以具体化（本质上是缓存），加快重复查询。如果视图后面的查询需要很长时间才能运行，则很有用。
- 有时用户需要访问表的一个子集，但不能被授予访问整个表的权限。您可以设置一个视图，该视图仅显示允许用户查看的行，并仅授予他们访问该视图的权限。
将查询保存为视图的好处是它将包含在数据库中。如果您的计算机出现问题并且您的保存文件已损坏，会发生什么情况？您将丢失这些查询。如果它们在数据库中，那么它们将始终存在并且可以通过您的备份恢复。
将所有查询保存在一个网络文件夹中，但也将它们创建为视图，以便可以在数据库中快速找到它们并在重复请求或为报告和仪表板创建数据源时引用它们。
视图还可以消除您在本地存储查询的需要，尤其是当它们是您经常使用的查询时。视图本质上使您能够将查询“保存”到数据库中，然后您可以像查询表一样查询该视图。
当你在一家拥有更大团队的大公司工作时，这实际上会变得更有用：如果你的团队总是使用一个通用的“查询结构”（即总是从同一个表中提取数据，使用相同的连接，使用相同的过滤，如“Active = 1”），而不是每个用户都需要复制他们自己的通用查询的“版本”，您可以通过视图拥有一个位于中心的“标准”版本的查询。然后每个人都只查询该视图。如果查询位于数据库的中心位置/在数据库中定义，则手动构建查询时出现查询偏差/错误的可能性较小。
在我的公司，只有 DBA 可以访问表——其他使用我们任何数据库中的数据的人都使用视图。这是为了保护我们数据的完整性。实际上，绝大多数数据只是被查询 - 数据输入来自各种自动化源/系统，因此确实不需要人们手动操作数据。如果需要更新/更改数据，则由具有特定访问权限的人员在前端完成。