我正在创建一个具有一些复杂基础关联的网络应用程序。为了解决我遇到的几个问题，我创建了一个 UNION 视图。可能还有很多其他方法可以解决这个问题。
但是我现在正在考虑我的设计效率，我想知道一个 VIEW 是每次查询时都新创建的，还是只创建一次，并保持更新。
详细地说，如果我有 table_a（100 条记录）和 table_b（100 条记录）并创建一个 UNION 视图，那么我创建了一个包含 200 条记录的视图。
每次我对视图进行选择时都会发生整个过程吗？
同样，显然每次我更新基础表记录时，视图都会更新，但是视图是更新这条记录还是从头开始重新创建整个视图？
戴尔
视图只不过是带有名称的查询。有可能与性能相关的优化，一些 DBMS 比其他的更好（pgSQL 似乎更好），比如重用查询计划、缓存访问控制等。
但是，在一天结束时，几乎总是可以期望视图的行为类似于直接发出 SQL。不同之处在于，您可以授予对此查询的访问权限，而无需授予对基础表的访问权限。
您可以进行一些优化来改变行为（使它们像半表一样），并且可能存在也可能不存在于 pgSQL 中，如物化视图（抱歉不知道 pgSQL），但这只是吹毛求疵。
使用 EXPLAIN 查看 VIEW 是如何执行的，您将看到与普通查询相同的结果。
EXPLAIN
SELECT * FROM name_of_your_view WHERE foo = 23;
PostgreSQL 将尝试优化内部查询，即使您加入视图、使用其他视图拥有视图等。尽量避免在优化器完成它的（伟大的）工作之前必须执行 VIEW 的情况。聚合、ORDER BY 和 LIMIT 是在嵌套视图中使用时潜在问题的示例。只需使用 EXPLAIN 即可查看发生了什么。
每次我对视图进行选择时都会发生整个过程吗？
是的。
非物化视图（PostgreSQL 不支持物化视图）只是一个准备好的 SQL 语句 - 通过将视图引用替换为包含视图所基于的 SELECT 的子查询，您将获得相同的性能。
这就是为什么每次在视图上运行查询时都会出现基于支持表的值的原因，我不清楚是否在不刷新视图的情况下在 PostgreSQL 中使列操作可见 - 即：如果基于 SELECT * FROM 创建视图table_x，然后从 table_x 添加或删除列 - 大多数数据库将要求您刷新视图以通过视图查看更改。
不鼓励在视图之上构建视图——它们很脆弱；直到运行一个依赖于另一个视图的视图才会知道是否有问题。并且没有性能提升 - 相反。代码重用在基于 SET 的环境中表现不佳......