我正在创建xxx，映射主表(如Products表)和引用表(如ProductType或ProductDescriptionByLanguage)之间的所有关系。这将创建一个视图，允许我检索产品及其从外键转换到描述的所有详细信息。 然后我可以使用ORM创建对象，轻松地构建网格、组合框等。

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

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

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

下面是如何使用视图以及权限来限制用户可以在表中更新的列。

/* This creates the view, limiting user to only 2 columns from MyTestTable */
CREATE VIEW dbo.myTESTview 
WITH SCHEMABINDING AS
SELECT ID, Quantity FROM dbo.MyTestTable;

/* This uses the view to execute an update on the table MyTestTable */
UPDATE dbo.myTESTview
SET Quantity = 7
WHERE ID = 1

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

例子:

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

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

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

一般来说，我使用视图是为了让生活更简单，从存储在多个表中的实体中获得扩展细节(消除代码中的大量连接以增强可读性)，有时还可以在多个数据库中共享数据，甚至可以使插入更容易阅读。