【发布时间】：2011-11-19 00:12:45
【问题描述】：
【问题讨论】：
【发布时间】：2011-11-19 00:12:45
【问题描述】：
它简化了调用并提供了一个间接层。
因此，如果您有一个包含大量连接的复杂选择，您可以在视图中实现它并简单地调用视图，而无需考虑所有这些连接。然后，您可以重复使用此视图。
此外，如果您以这种方式使用视图而不是表，那么将来如果您需要迁移列，您可以轻松地做到这一点，并且只需要更改视图。
【讨论】：
有几个，但我认为主要的好处是视图是逻辑数据独立性的 SQL 实现。
构建一个可更新的视图，使用该视图的应用程序相对不受基础表更改的影响。更改基础表的结构，更新视图定义，所有应用程序都像什么都没发生一样工作。 （在遗留数据库上，可能有数百个用几十种语言编写的应用程序。这是 大 胜利。）
其他好处（用 Chris Date 解释）
隐藏数据的“自动”安全性。限制对视图的访问，您可以细粒度地控制谁可以看到什么。
应用程序的“干燥”能力。视图可以为复杂的 SELECT 语句提供一个简单的公共接口，因此应用程序只需 SELECT column-list FROM my-easy-view。
不同的用户可以通过不同的方式查看相同的数据。
【讨论】：
-
“更改基础表的结构，更新视图定义，所有应用程序都像什么都没发生一样工作。” SQL查询？每个使用更新后的 SQL 查询的应用程序也可以，不是吗？
-
@SebNag: " 简单地更新 SQL 查询难道不够吗？" 嗯，不是真的。首先，如果不是数百个，则更有可能涉及多个查询。 （我曾经在一个有 20,000 个基表的 ERP 系统上工作。我从未尝试计算视图。）其次，尽管您可以更新可能数百个查询而不会出错并获得与构建可更新视图的效果相同，这也需要对这数百个查询进行回归测试。更容易对一两个可更新视图进行回归测试。
除了 Oded 提到的明显好处之外，您有时还可以通过使用 materialized views 显着提高速度。来自维基百科：
在遵循关系模型的数据库管理系统中，视图是表示数据库查询结果的虚拟表。每当查询或更新普通视图的表时，DBMS 会将这些转换为针对基础基表的查询或更新。物化视图采用不同的方法，其中查询结果被缓存为具体表，可以不时从原始基表中更新。
【讨论】：