我正在阅读 SQL Server 2008 圣经，并且正在介绍视图部分。但是作者确实没有解释视图的目的。视图有什么用处？我应该在我的网站中使用它们吗？它们有什么好处？
【问题讨论】：
标签： sql sql-server
之前的答案似乎都没有提到的另一个用途是更容易部署表结构更改。
假设您希望停用包含活动用户数据的表 (T_OLD)，而是使用具有相似数据的新表（名为 T_NEW）但同时包含活动和非活动用户的数据，多一列active。
如果您的系统有大量查询来执行SELECT whatever FROM T_OLD WHERE whatever，那么您有两种推出选择：
1) Cold Turkey - 更改数据库，同时更改、测试和发布包含上述查询的大量代码。很难做（甚至协调），风险很大。不好。
2) 渐进 - 通过创建 T_NEW 表、删除 T_OLD 表并创建一个名为 T_OLD 的 VIEW 来更改数据库T_OLD 表 100%（例如视图查询是 SELECT all_fields_except_active FROM T_NEW WHERE active=1）。
这将允许您避免发布当前从 T_OLD 中选择的任何代码，并在闲暇时进行更改以将代码从 T_OLD 迁移到 T_NEW。
这是一个简单的例子，还有很多其他的例子。
附：另一方面，您可能应该有一个存储过程 API，而不是来自 T_OLD 的直接查询，但情况并非总是如此。
【讨论】：
（复制自 Google 搜索中出现的第一个教程（链接现已失效），但它具有我自己手动输入的所有好处。）
视图有以下好处：
- 安全 - 用户可以访问视图，而不能直接访问基础表。这允许 DBA 仅向用户提供他们需要的数据，同时保护同一个表中的其他数据。
- 简单性 - 视图可用于隐藏和重用复杂查询。
- 列名简化或澄清 - 视图可用于为列名提供别名，以使它们更容易记住和/或更有意义。
- 垫脚石 - 视图可以在“多级”查询中提供垫脚石。例如，您可以创建一个查询视图，该视图计算每个销售人员的销售额。然后，您可以查询该视图，按销售人员的销售额对他们进行分组。
【讨论】：
来自Wikipedia的一些原因：
视图可以提供优于表格的优势：
【讨论】：
VIEWS 可以用作 SELECT/CODE 的可重用部分，可以包含在要加入的其他选择/查询中，并使用各种不同的过滤器，而不必每次都重新创建整个 SELECT。
这还将逻辑放置在一个位置，因此您不必在整个代码库中更改它。
看看
Choice Between Stored Procedures, Functions, Views, Triggers, Inline SQL
视图的主要美在于它 在大多数情况下可以像桌子一样使用 情况，但与表不同，它可以 封装非常复杂的计算 和常用的连接。它还可以 使用数据库中的几乎任何对象 除了存储过程。意见 当您总是需要时最有用 加入同一组表说 带有订单详细信息的订单以获取 汇总计算字段等
【讨论】：
视图是一个抽象层，它做任何好的抽象层所做的事情，包括封装数据库模式和保护您免受更改内部实现细节的后果。
这是一个界面。
【讨论】：
这里有很多使用视图而不是直接使用表格的原因
【讨论】：
这是使用视图通过某些标准约束实体的一种非常常见的用法。
表：USERS 包含所有用户
查看：ACTIVE_USERS 包含所有用户，不包括那些被暂停、禁止、等待激活并且不符合您将来可能选择定义为活动要求的一部分的任何标准的用户。如果您选择不删除，则无需从 USERS 表中删除任何行，因为 ACTIVE_USERS 始终可以隐藏不需要的行。
这样，您可以在用户管理页面中使用该表，但应用程序的其余部分可以使用 ACTIVE_USERS，因为他们可能是唯一应该能够执行流程和访问/修改数据的用户。
【讨论】：
视图可以让您组合来自多个不同表的数据并对其进行格式化（组合字段、提供更有意义的字段名称等），以便最终用户使用起来更轻松。它们是数据库模型的抽象。它们还可用于让用户访问表中的数据，而无需直接访问表本身。
【讨论】：
常见原因/用途的小清单：
使用它们来更改格式或 数据的“外观”（即您可能加入一个 名字和姓氏一起）
执行计算或其他查找 关于数据
非规范化数据（从 几张桌子放在一个地方）
【讨论】：
观点是邪恶的！尽可能避免使用它们，仅出于 DVK 提到的原因使用它们 - 临时数据迁移。
您应该了解，在包含 100 个表的数据库中，很难记住每个表的用途。现在，如果您在此处添加另外 300 个视图，它将变得一团糟。比“视图爱好者”更倾向于使用嵌套视图，然后在存储过程中使用嵌套视图。我个人现在使用一个数据库，其中有 4 次深度嵌套的视图！ 因此，要了解存储过程的最简单逻辑，我必须先浏览所有视图。
【讨论】：