什么时候以及为什么有些人决定他们需要在他们的数据库中创建一个视图?为什么不运行一个普通的存储过程或选择?


当前回答

这并没有确切地回答你的问题,但我认为值得一提的是物化视图。我的经验主要是使用Oracle,但是SQL-Server应该是相当相似的。

We used something similar in our architecture to address XML performance problems. Our systems are designed with a lot of data stored as XML on a row and applications might need to query particular values within it. Handling lots of XMLTypes and running XPaths across large number of rows has a large impact on performance so we use a form of materialized views to extract the desired XML nodes out into a relational table anytime the base table changes. This effectively provides a physical snapshot of the query at a point in time as opposed to standard views which would run their query on demand.

其他回答

当我想要查看一个表的快照和/或视图(以只读方式)时

这样做的原因不止一个。有时可以使通用连接查询变得简单,因为可以只查询表名而不是执行所有的连接。

另一个原因是将数据限制为不同的用户。例如:

表1:列- USER_ID;用户名;SSN

管理用户可以在实际表上有私权,但你不想访问的用户,比如SSN,你创建一个视图

CREATE VIEW USERNAMES AS SELECT user_id, username FROM Table1;

然后给他们访问视图而不是表的私权。

视图是查询的封装。转换为视图的查询往往比较复杂,因此将它们保存为视图以供重用是有好处的。

一般来说,我使用视图是为了让生活更简单,从存储在多个表中的实体中获得扩展细节(消除代码中的大量连接以增强可读性),有时还可以在多个数据库中共享数据,甚至可以使插入更容易阅读。

这并没有确切地回答你的问题,但我认为值得一提的是物化视图。我的经验主要是使用Oracle,但是SQL-Server应该是相当相似的。

We used something similar in our architecture to address XML performance problems. Our systems are designed with a lot of data stored as XML on a row and applications might need to query particular values within it. Handling lots of XMLTypes and running XPaths across large number of rows has a large impact on performance so we use a form of materialized views to extract the desired XML nodes out into a relational table anytime the base table changes. This effectively provides a physical snapshot of the query at a point in time as opposed to standard views which would run their query on demand.