为什么你在数据库中创build一个视图？
什么时候和为什么有人决定他们需要在他们的数据库中创build一个视图？ 为什么不运行一个正常的存储过程或select？
一个观点提供了几个好处。
1.意见可以隐藏复杂性
如果你有一个需要连接多个表的查询，或者有复杂的逻辑或计算，你可以将所有的逻辑编码到一个视图中，然后从视图中select，就像你在一个表中。
2.视图可以用作安全机制
视图可以从表中select某些列和/或行，并在视图上设置权限而不是基础表。 这允许仅显示用户需要查看的数据。
3.视图可以简化对遗留代码的支持
如果您需要重构可能会破坏大量代码的表，则可以用相同名称的视图replace表。 该视图提供了与原始表完全相同的模式，而实际模式已更改。 这可以保持引用表的遗留代码不中断，让您在闲暇时更改遗留代码。
这些只是视图如何有用的许多例子中的一部分。
除此之外，它可以用于安全。 如果您有“客户”表，则可能要让所有销售人员访问姓名，地址，邮编等字段，而不是credit_card_number。 您可以创build一个只包含他们需要访问的列的视图，然后授予他们在视图上的访问权限。
一个视图是一个查询的封装。 查看转换为视图往往是复杂的，因此将它们保存为重用视图可能是有利的。
我通常会创build视图来取消归一化和/或汇总经常用于报告目的的数据。
编辑
通过阐述，如果我有一个数据库，其中一些实体是人员，公司，angular色，所有者types，订单，订单明细，地址和电话，人员表格存储员工和联系人以及地址和电话号码表为个人和公司存储电话号码，开发小组负责生成报告（或向非开发人员提供报告数据），例如员工销售，客户销售或地区销售，按月销售，国家的客户等等。我会创build一套视图，将数据库实体之间的关系解除规范化，从而使现实世界实体的更加一体化的观点（没有双关语意思）可用。 其中一些好处可能包括：
- 减less编写查询的冗余
- build立相关实体的标准
- 为复杂计算和连接提供评估和最大化性能的机会（例如，在MSSQL中的Schemabound视图上编制索引）
- 使团队成员和非开发人员的数据更容易访问和直观。
几个原因：如果你有复杂的连接，有时候最好有一个视图，以便任何访问总是有正确的连接，开发人员不必记住他们可能需要的所有表。 通常情况下，这可能是财务应用程序，所有财务报告都基于同一组数据是非常重要的。
如果你有用户，你想限制他们可以看到的logging，你可以使用一个视图，让他们只访问视图而不是基础表，然后查询视图
水晶报告似乎更喜欢使用视图来存储特效，所以做大量报表写作的人往往会使用大量的视图
视图在重构数据库时也非常有用。 您通常可以隐藏更改，以便旧代码不会通过创build视图来看到它。 阅读重构数据库，看看这是如何工作，因为这是一个非常强大的重构方式。
查看存储过程的一个主要优点是可以像使用表一样使用视图。 也就是说，可以直接在查询的FROM子句中引用视图。 例如， SELECT * FROM dbo.name_of_view 。
几乎所有其他的方式，存储过程更强大。 你可以传入参数，包括out参数，允许你一次返回多个值，你可以做SELECT ， INSERT ， UPDATE和DELETE操作等等。
如果您希望View能够从FROM子句中进行查询，但是您也希望能够传入参数，那么也有办法做到这一点。 它被称为表值函数。
这是一个非常有用的文章：
编辑：顺便说一下，这种问题提出了一个观点有什么优势超过一个表值函数？ 我没有一个很好的答案，但我会注意到创build视图的T-SQL语法比表值函数更简单，数据库的用户可能更熟悉视图。
它可以作为你的ORM和你的表之间的一个很好的“中间人”。
例：
我们有一个Person表，我们需要改变它的结构，所以列SomeColumn将被移动到另一个表，并将有一对多的关系。
然而，就人而言，系统的大部分仍然使用SomeColumn作为单一的东西，并不是很多东西。 我们使用了一个视图来把所有的SomeColumns放在一起，并把它放在视图中，这个效果很好。
这是因为数据层已经改变了，但是业务需求没有根本改变，所以业务对象不需要改变。 如果业务对象不得不改变，我不认为这是一个可行的解决scheme，但意见绝对是一个好的中间点。
这是两个常见的原因：
您可以使用它来保证安全。 在主表上授予权限并创build限制列或行访问的视图，并授予用户查看视图的权限。
你可以使用它来方便。 join一起在视图中一直使用的一些表格。 这可以使查询一致，更容易。
有不止一个理由这样做。 有时，通用联接查询很容易，因为只能查询表名而不是进行所有联接。
另一个原因是限制数据给不同的用户。 举个例子：
表1：Colums – USER_ID; USERNAME; SSN
pipe理员用户可以在实际表上拥有权限，但是您不想访问的用户说SSN，您创build一个视图为
CREATE VIEW USERNAMES as SELECT user_id，username FROM Table1;
然后给他们privs访问视图，而不是表格。
在对遗留数据库进行报告时，视图可能是天赐之物。 特别是，您可以使用感性的表名而不是隐藏的5个字母的名称（其中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
当我想要查看表格的快照和/或查看 （以只读方式）
当我只运行查询时，我喜欢使用存储过程的视图。 视图还可以简化安全性，可以用来简化对多个表的插入/更新，并可用于快照/实现数据（运行长时间运行的查询，并保持结果caching）。
我已经使用物化视图来实时查询不需要保持准确的查询。
视图也将非常复杂的configuration和表分解成易于查询的可pipe理块。 在我们的数据库中，我们的整个表pipe理系统从一个大表中分解成视图。
这不能完全回答你的问题，但我认为这将是值得一提的物化视图 。 我的经验主要是甲骨文，但据说SQL-Server是相当类似的。
我们在架构中使用了类似的东西来解决XML性能问题。 我们的系统被devise成在行上以XML格式存储大量数据，应用程序可能需要查询其中的特定值。 处理大量的XMLTypes并在大量的行上运行XPaths对性能有很大的影响，所以我们使用一种物化视图的forms在基表发生变化时，将所需的XML节点抽出到关系表中。 这有效地提供了查询在某个时间点的物理快照，而不是按照需要运行查询的标准视图。
我看到一个存储过程更像一个我可以调用我的数据的方法，而对于我来说，一个视图提供了一种机制来创build基本数据的合成版本，可以根据这个数据创build查询或存储过程。 我会创build一个视图，当简化或聚合是有道理的。 我想写一个存储过程，当我想提供一个非常具体的服务。
关于视图的一个好奇之处在于它们被Microsoft Access视为表格：当您使用ODBC将Microsoft Access前端附加到SQL数据库时，可以在可用表格列表中看到表格和视图。 所以如果你在MS Access中准备复杂的报表，你可以让SQL服务器进行连接和查询，大大简化你的生活。 在MS Excel中准备查询也是如此。
通常，我使用视图来简化生活，从一些存储在多个表中的实体中获取扩展细节（消除代码中的大量连接以增强可读性），并且有时在多个数据库上共享数据，甚至使插入操作更易于阅读。
我的生产数据库中只有10个左右的视图。 我使用几个我一直使用的列。 我使用的一组数据来自7个表，有些使用外部连接，而不是不断地重写，我只需要在select中调用这个视图并进行一个或两个连接。 对我来说，这只是一个节省时间。
我创buildxxx映射主表（如Products表）和参考表（如ProductType或ProductDescriptionByLanguage）之间的所有关系。 这将创build一个视图，这将允许我检索产品，并将其所有的细节从其外键翻译成其描述。 然后我可以使用ORM创build对象来轻松地构build网格，combobox等。
专注于特定的数据视图允许用户专注于他们感兴趣的特定数据以及他们所负责的特定任务。 不必要的数据可以不在视图中。 这也增加了数据的安全性，因为用户只能看到视图中定义的数据，而不能看到底层表中的数据。 有关使用视图出于安全目的的更多信息，请参阅使用视图作为安全机制。
简化数据操作视图可以简化用户操作数据的方式。 您可以将频繁使用的联接，投影，UNION查询和SELECT查询定义为视图，以便用户不必在每次对该数据执行附加操作时指定所有条件和限定条件。 例如，用于报告目的并执行子查询，外部联接以及从一组表中检索数据的复杂查询可以创build为视图。 该视图简化了对数据的访问，因为每次生成报表时都不必写入或提交基础查询; 该视图被查询。 有关操作数据的更多信息。
您还可以创build内联的用户定义的函数，这些函数在逻辑上作为参数化视图运行，或者在WHERE子句search条件中具有参数的视图。 有关更多信息，请参阅内联用户定义的函数。
自定义数据视图允许不同的用户以不同的方式查看数据，即使他们正在同时使用相同的数据。 当具有许多不同兴趣和技能水平的用户共享相同的数据库时，这是特别有利的。 例如，可以创build仅检索客户经理处理的客户的数据的视图。 该视图可以根据使用该视图的客户经理的loginID来确定要检索哪些数据。
导出和导入数据视图可用于将数据导出到其他应用程序。 例如，您可能希望使用pubs数据库中的商店和销售表来分析使用Microsoft®Excel的销售数据。 为此，您可以创build基于商店和销售表的视图。 然后可以使用bcp实用程序来导出视图定义的数据。 也可以使用bcp实用程序或BULK INSERT语句将数据导入到数据文件的某些视图中，前提是可以使用INSERT语句将行插入到视图中。 有关将数据复制到视图的限制的更多信息，请参见INSERT。 有关使用bcp实用程序和BULK INSERT语句将数据复制到视图和从视图复制数据的详细信息，请参阅复制到或从视图。
组合分区数据 Transact-SQL UNION集合运算符可以在视图中使用，以将来自不同表格的两个或更多个查询的结果合并为一个结果集。 这对用户来说显示为一个称为分区视图的表。 例如，如果一张表包含华盛顿的销售数据，而另一张表包含加利福尼亚州的销售数据，则可以从这些表的联盟创build视图。 该视图代表两个地区的销售数据。 要使用分区视图，可以创build多个相同的表，指定一个约束来确定可以添加到每个表的数据范围。 然后使用这些基表创build视图。 查询视图时，SQL Server自动确定哪些表受到查询的影响，并仅引用这些表。 例如，如果查询指定仅需要华盛顿州的销售数据，则SQL Server只读取包含华盛顿销售数据的表; 没有其他表被访问。
分区视图可以基于来自多个异构源（例如远程服务器）的数据，而不仅仅是相同数据库中的表。 例如，要组合来自不同远程服务器的数据（每个远程服务器存储组织中不同区域的数据），可以创build分布式查询，从每个数据源检索数据，然后根据这些分布式查询创build视图。 任何查询只读取远程服务器上包含查询所请求的数据的表中的数据; 视图中分布式查询所引用的其他服务器不被访问。
在跨多个表或多个服务器分区数据时，只能访问部分数据的查询可以运行得更快，因为要扫描的数据较less。 如果表位于不同的服务器上，或者位于具有多个处理器的计算机上，则也可以并行扫描查询中涉及的每个表，从而提高查询性能。 另外，维护任务（如重build索引或备份表）可以更快地执行。 通过使用分区视图，数据仍然显示为单个表，并且可以查询而无需手动引用正确的基础表。
如果满足以下任一条件，则分区视图可更新：在视图上定义INSTEAD OF触发器，并使用支持INSERT，UPDATE和DELETE语句的逻辑。
视图和INSERT，UPDATE和DELETE语句都遵循为可更新分区视图定义的规则。 有关更多信息，请参阅创build分区视图。
https://technet.microsoft.com/en-us/library/aa214282(v=sql.80).aspx#sql:join
把它看作是重构你的数据库模式。
我想第一个。要隐藏查询的复杂性。 它是非常适合的意见。如何当我们正常化数据库表增加。现在提取数据是非常困难的时候表的数量增加。所以最好的方式来处理是后续views.If我错了正确的我。
我们创build视图来限制或禁止访问表中的所有行/列。如果所有者希望只有特定或有限的行/列需要共享，那么他将创build一个与这些列的视图。
