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

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

视图相对于存储过程的一个主要优点是，您可以像使用表一样使用视图。也就是说，可以在查询的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语法比创建表值函数要简单，数据库用户可能更熟悉视图。

它可以作为ORM和表之间的“中间人”。

例子:

我们有一个Person表，我们需要改变它的结构，以便将SomeColumn列移动到另一个表，并与之有一对多的关系。

然而，系统的大多数情况下，就Person而言，仍然将SomeColumn作为一个单独的东西使用，而不是很多东西。我们使用一个视图将所有的SomeColumns聚集在一起，并将其放在视图中，效果很好。

这是可行的，因为数据层发生了变化，但业务需求没有根本变化，因此业务对象不需要更改。如果业务对象必须改变，我不认为这是一个可行的解决方案，但视图绝对是一个很好的中间点。

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

这并没有确切地回答你的问题，但我认为值得一提的是物化视图。我的经验主要是使用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个连接。对我来说，这只是节省时间。