数据库视图与 Select 查询？
DB View vs Select query?
阅读关于 SO/Google 的其他类似问题后，我得到数据库视图（Virtual/Simple table 视图不是物化视图）主要用于方便和安全，而不是用于提高速度。有人说视图是可重用的并且位于中心位置，但也可以在代码中将其保留在中心位置
根据我的理解 当来自 Web 服务器时，视图应该比查询稍微好一些。原因是当通过 Web 服务器中的代码执行查询时，查询文本需要在网络上传输，而在视图中则不是这样。我相信查询（准备语句）和视图都是预编译的？ .在这个意义上也是一样。 我的理解对吗？
这个resource说反了
Performance – What may seem like a simple query against a view could
turn out to be a hugely complex job for the database engine. That is
because each time a view is referenced, the query used to define it,
is rerun.
但这也适用于查询。不是吗？
此问题针对的是简单视图，而非 materialized/indexed 视图
参考资源为
Is a view faster than a simple query?
Query vs. View
（这里说的是 Oracle，因为那是我的知识领域）
视图并非 "pre-compiled" 本身。它们只是存储的文本，因此在概念上，当您 运行
select * from my_view
逻辑上等同于
select * from ( [query that defines view] )
关于
"Reason is when query is executed through code in Web server, the query text needs to travel on network which is not the case in views"
这是事实，但是您的 Web 服务器和数据库很少被如此糟糕的网络分开，以至于针对视图的 100 字节查询与针对基础的 500 字节查询 tables会很明显。
最后，关于性能，这取决于视图。在查询中引用视图时，有两种机制可能会起作用。
一个是"view merging"，我们可以将视图的文本集成到查询中，就好像视图从未存在过一样，例如
view: select * from t
query: select * from my_view where x=1
可以合并为：
select * from t where x=1
因此视图的文本从未真正执行过。
但另一种选择是 "view resolution"，其中视图足够复杂或包含禁止合并的定义。例如，包含 window 函数的视图：
view: select t.*, row_number() over ( order by blah ) from t
query: select * from my_view where x=1
无法合并到：
select t.*, row_number() over ( order by blah ) from t
where x=1
因为 window 函数将不再 return 相同的结果。 （一个 return 是整个 table 的排名，另一个 return 是仅针对 x=1 的行的排名。
所以在视图分辨率的情况下，您可以看到性能影响，但这仅仅是因为我们需要保证结果的正确性，而不是通过一般的视图限制。
阅读关于 SO/Google 的其他类似问题后，我得到数据库视图（Virtual/Simple table 视图不是物化视图）主要用于方便和安全，而不是用于提高速度。有人说视图是可重用的并且位于中心位置，但也可以在代码中将其保留在中心位置
根据我的理解 当来自 Web 服务器时，视图应该比查询稍微好一些。原因是当通过 Web 服务器中的代码执行查询时，查询文本需要在网络上传输，而在视图中则不是这样。我相信查询（准备语句）和视图都是预编译的？ .在这个意义上也是一样。 我的理解对吗？
这个resource说反了
Performance – What may seem like a simple query against a view could turn out to be a hugely complex job for the database engine. That is because each time a view is referenced, the query used to define it, is rerun.
但这也适用于查询。不是吗？
此问题针对的是简单视图，而非 materialized/indexed 视图
参考资源为 Is a view faster than a simple query?
Query vs. View
（这里说的是 Oracle，因为那是我的知识领域）
视图并非 "pre-compiled" 本身。它们只是存储的文本，因此在概念上，当您 运行
select * from my_view
逻辑上等同于
select * from ( [query that defines view] )
关于
"Reason is when query is executed through code in Web server, the query text needs to travel on network which is not the case in views"
这是事实，但是您的 Web 服务器和数据库很少被如此糟糕的网络分开，以至于针对视图的 100 字节查询与针对基础的 500 字节查询 tables会很明显。
最后，关于性能，这取决于视图。在查询中引用视图时，有两种机制可能会起作用。
一个是"view merging"，我们可以将视图的文本集成到查询中，就好像视图从未存在过一样，例如
view: select * from t
query: select * from my_view where x=1
可以合并为：
select * from t where x=1
因此视图的文本从未真正执行过。
但另一种选择是 "view resolution"，其中视图足够复杂或包含禁止合并的定义。例如，包含 window 函数的视图：
view: select t.*, row_number() over ( order by blah ) from t
query: select * from my_view where x=1
无法合并到：
select t.*, row_number() over ( order by blah ) from t
where x=1
因为 window 函数将不再 return 相同的结果。 （一个 return 是整个 table 的排名，另一个 return 是仅针对 x=1 的行的排名。
所以在视图分辨率的情况下，您可以看到性能影响，但这仅仅是因为我们需要保证结果的正确性，而不是通过一般的视图限制。