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


当前回答

视图相对于存储过程的一个主要优点是,您可以像使用表一样使用视图。也就是说,可以在查询的FROM子句中直接引用视图。例如,SELECT * FROM dbo.name_of_view。

在几乎所有其他方面,存储过程都更强大。你可以传入参数,包括输出参数,让你一次有效地返回几个值,你可以做SELECT, INSERT, UPDATE和DELETE操作,等等。

如果你想要一个View能够从from子句中进行查询,但你也想要能够传入参数,也有一种方法可以做到这一点。它叫做表值函数。

这里有一篇关于这个主题的非常有用的文章:

http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html

编辑:顺便说一下,这就提出了一个问题,视图比表值函数有什么优势?对此,我没有一个很好的答案,但我要指出,创建视图的T-SQL语法比创建表值函数要简单,数据库用户可能更熟悉视图。

其他回答

我认为第一个。隐藏查询的复杂性。它非常适合于视图。当我们规范化数据库表时如何增加。现在,当表数量增加时,获取数据是非常困难的。所以最好的处理方法是遵循视图。如果我错了,请纠正我。

这并没有确切地回答你的问题,但我认为值得一提的是物化视图。我的经验主要是使用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.

当我只运行查询时,我喜欢在存储过程上使用视图。视图还可以简化安全性,可用于简化对多个表的插入/更新,并可用于快照/物化数据(运行长时间运行的查询,并保持结果缓存)。

我使用物化视图来执行不需要实时保持准确的查询。

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

我的生产数据库中只有10个左右的视图。我用了几个我一直在用的列。我使用的一组来自7个表,一些具有外部连接,而不是不断重写,我只需要在一个选择中调用该视图,并使一个或2个连接。对我来说,这只是节省时间。