Question

视图如何充当实际表和最终用户之间的中介？什么是创建视图时发生的内部过程。我的意思是，当在桌面上创建视图时，它是否就像桌子和最终用户之间的墙壁或者其他？视图如何保护实际表，只有检查选项？但是如果用户直接插入表中，那么我该如何保护实际的表呢？

如果他/她不使用：insert into **vw** values()，但使用：insert into **table_name** values()，那么表格现在如何受到保护？

Answer 1

非物化视图只是预先打包的SQL查询。它们的执行方式与任何派生表/内联视图相同。对同一视图的多次引用将运行视图包含的每个引用的查询。 IE：

CREATE VIEW vw_example AS
  SELECT id, column, date_column FROM ITEMS

SELECT x.*, y.*
  FROM vw_example x
  JOIN vw_example y ON y.id = x.id

......转化为：

SELECT x.*, y.*
  FROM (SELECT id, column, date_column FROM ITEMS) x
  JOIN (SELECT id, column, date_column FROM ITEMS) y ON y.id = x.id

缓存

主要好处是缓存，因为查询将是相同的。缓存查询（包括执行计划），以便稍后更快地运行查询，因为已经生成了执行计划。缓存通常要求查询与区分大小写相同，并最终到期。

Predicate Pushing

另一个潜在的好处是视图通常允许“谓词推送”，其中视图上指定的条件可以被推送到优化器所表示的查询中。这意味着查询可以扫描表一次，而不是扫描表以便将结果集呈现给外部/终极查询。

SELECT x.*
  FROM vw_example x
 WHERE x.column = 'y'

...可以被优化器解释为：

SELECT id, column, date_column 
  FROM ITEMS
 WHERE x.column = 'y'

谓词推送的决定完全取决于优化器。我不知道开发人员有任何强制决定的能力，只是它确实取决于视图使用的查询以及正在应用的其他标准。

遗憾的是，非常常见的非物化SQL视图仅用于封装以简化编写查询 - 简化也不是推荐的做法。 SQL是基于SET的，并且使用过程方法不能很好地优化。将视图叠加在一起也不是推荐的做法。

非物化视图也是可更新的，但是存在限制，因为可以将多个表连接在一起构成视图。可更新的非物化视图将阻止用户插入新记录，但可以更新现有记录。 The CHECK OPTION depends on the query used to create the view for enforcing a degree of update restriction, but it's not enough to ensure none will ever happen。这表明，防止不需要的添加/编辑/删除的唯一可靠方法是grant proper privileges to the user，最好是通过角色。

Answer 2

视图不保护表，但可以在基于权限的表保护方案中使用它们。视图只是提供访问表的便捷方式。如果您授予用户访问视图而不是表的权限，那么您可能会极大地限制访问权限。