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

我认为第一个。隐藏查询的复杂性。它非常适合于视图。当我们规范化数据库表时如何增加。现在，当表数量增加时，获取数据是非常困难的。所以最好的处理方法是遵循视图。如果我错了，请纠正我。

以下是两个常见的原因:

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

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

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

/* 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聚集在一起，并将其放在视图中，效果很好。

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

这样做的原因不止一个。有时可以使通用连接查询变得简单，因为可以只查询表名而不是执行所有的连接。

另一个原因是将数据限制为不同的用户。例如:

表1:列- USER_ID;用户名;SSN

管理用户可以在实际表上有私权，但你不想访问的用户，比如SSN，你创建一个视图

CREATE VIEW USERNAMES AS SELECT user_id, username FROM Table1;

然后给他们访问视图而不是表的私权。