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

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

可以把它看作重构数据库模式。

我们创建view来限制或严格访问表中的所有行/列。如果所有者希望只有特定或有限的行/列需要共享，那么他将使用这些列创建一个视图。

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

例子:

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

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

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

在我看来，存储过程更多的是一种可以针对数据调用的方法，而视图提供了一种机制来创建基础数据的合成版本，可以根据它创建查询或存储过程。当简化或聚合有意义时，我将创建一个视图。当我想提供一个非常特定的服务时，我将编写一个存储过程。