为了安全性:仅允许每个用户通过包含用户或用户组有权查看的特定数据的一小组视图访问数据库，限制用户对其他数据的访问。

查询和结构的简单性:视图可以从多个表中提取数据并呈现单个表，简化信息并将多表查询转换为视图的单表查询，它为用户提供数据库结构的特定视图，将数据库呈现为特定用户或用户组的一组虚拟表。

为了创建一致的数据库结构:即使底层源表发生了更改，视图也会显示一致的、未更改的数据库结构映像。

视图提供了几个好处。

1. 视图可以隐藏复杂性

如果您有一个需要连接几个表的查询，或者有复杂的逻辑或计算，您可以将所有这些逻辑编码到一个视图中，然后像处理表一样从视图中进行选择。

2. 视图可以用作一种安全机制

视图可以从一个(或多个)表中选择某些列和/或行，并在视图上而不是在底层表上设置权限。这允许只显示用户需要查看的数据。

3.视图可以简化对遗留代码的支持

如果您需要重构一个会破坏大量代码的表，您可以用同名的视图替换这个表。视图提供了与原始表完全相同的模式，而实际的模式已经更改。这可以防止引用表的遗留代码中断，允许您在空闲时更改遗留代码。

这些只是展示视图如何有用的众多示例中的一些。

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

以下是两个常见的原因:

你可以用它来保证安全。在主表上不授予权限，创建限制列或行访问的视图，并向用户授予查看视图的权限。

你可以为了方便使用它。将视图中经常使用的一些表连接在一起。这可以使查询保持一致并更容易。

它可以作为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.