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

几个原因: 如果您有复杂的连接，有时最好有一个视图，这样任何访问都会有正确的连接，开发人员不必记住他们可能需要的所有表。通常情况下，这可能用于财务应用程序，其中所有财务报告都基于同一组数据，这是非常重要的。

如果你有用户，你想限制他们可以看到的记录，你可以使用一个视图，只给他们访问视图，而不是底层表，然后查询视图

Crystal报表似乎更喜欢使用视图来存储过程，因此编写大量报表的人倾向于使用大量视图

视图在重构数据库时也非常有用。您通常可以通过创建一个视图来隐藏更改，以便旧代码看不到它。阅读重构数据库的相关内容，了解它是如何工作的，因为这是一种非常强大的重构方式。

在其他方面，它可以用于安全。如果您有一个“customer”表，您可能希望让所有销售人员访问名称、地址、邮政编码等字段，但不允许credit_card_number。您可以创建一个只包含他们需要访问的列的视图，然后授予他们对视图的访问权。

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

例子:

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

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

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

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

视图还将非常复杂的配置和表分解为易于查询的可管理块。在我们的数据库中，整个表管理系统被分解为来自一个大表的视图。