设计良好的应用程序通常会在保持实现细节私有性的同时公开一个公共接口，从而在不影响终端用户的情况下支持将来的设计变动。在设计数据库时，通过保持表的私有性并允许用户仅通过一组视图访问数据，你可以获得类似的结果。本章致力于定义什么是视图、如何创建它们、何时使用它们以及如何使用它们。
视图其实就是一种数据查询机制。与表不同，视图不涉及数据存储，可以通过命名select语句来创建视图，将其保存以供其他人使用。其他用户可以使用该视图访问数据，就像他们直接查询表一样。
举一个简单的例子，假设你希望部分隐藏cUStoMeR表中的电子邮件地址。例如，市场营销部门可能需要访问电子邮件地址才能发布促销广告，但公司的隐私政策有规定必须保证这些数据的安全。因此不允许直接访问cUStoMeR表，而是定义一个名为cUStoMeR_vw的视图，并授权给所有非营销人员使用以访问客户数据。
语句的第一部分列出了视图的列名，这些列名可能与基础表的列名不同。语句的第二部分是select语句，它必须为视图中的每一列提供一个表达式。email列的生成方法是：获取电子邮件地址的前两个字符，与”*****”连接，然后与电子邮件地址的最后四个字符连接。
执行cReate view语句时，数据库服务器只简单地存储视图定义以供将来使用。若不执行查询，也就不会检索或存储任何数据。创建视图后，用户可以像查询表一样使用它进行查询。
尽管cUStoMeR_vw视图定义包含cUStoMeR表的四列，但前面的查询只检索其中三列。正如你将在本章后面看到的，如果视图中的某些列被附加到函数或子查询，那么这会是一个重要的区别。
从用户的角度来看，视图看起来就像一个表。要想知道视图中有哪些列是可用的，可以使用MySQL的descRibe命令查看。
在通过视图进行查询时，可以自由使用select语句中的任何子句，包括gRoup by、having和oRdeR by。
此查询将cUStoMeR_vw视图与payment表连接，以查找租赁电影花费了11美元或更多金额的客户。
在上一节中，我演示了一个简单的视图，它的目的是掩盖cUStoMeR.email列。虽然视图通常被用于此种目的，但还有更多理由使用视图。
如果你创建一个表并允许用户查询，那么他们将能够访问表中的每一列和每一行数据。但正如我前面提到的，你的表中有些列可能包含敏感信息，比如身份证号或信用卡号码，把包括这些敏感数据在内的表数据公开给用户访问绝对不是一个好主意。
如果你创建一个表并允许用户查询，那么他们将能够访问表中的每一列和每一行数据。但正如我前面提到的，你的表中有些列可能包含敏感信息，比如身份证号或信用卡号码，把包括这些敏感数据在内的表数据公开给用户访问绝对不是一个好主意。
报表程序通常需要聚合数据，而视图就是一种实现该功能的很好的方法，可以使数据看起来像是已经被预聚合并存储在数据库中。
部署视图最常见的原因之一是为了保护终端用户不受复杂性的影响。
一些数据库设计将大型表分解为多个小块以提高性能。例如，如果payment表变大了，设计者可能会决定将其分为两个表：payment_cuRRent(保存最近六个月的数据)和payment_HisTorical(保存六个月前的所有数据)。
如果为用户提供了一组用于数据检索的视图，但如果用户还要修改同一数据，又该怎么办呢?
虽然单表视图确实很常见，但你遇到的许多视图都会在基础查询的fRoM子句中包含多个表。
此版本的语句包含跨两个不同表的列，结果抛出异常。为了通过复杂视图插入数据，你需要知道每个列的来源。