使用 SQL 视图的好理由是什么？

我正在阅读 SQLServer2008圣经，并且我正在讨论视图部分。但作者确实没有解释 目的的观点。视图的有效用途是什么？我应该在我的网站上使用它们吗? 它们的好处是什么？

105276 次浏览
小开

VIEWS 可以用作 SELECT/CODE 的可重用部分，可以包含在其他选择/查询中，并使用各种不同的过滤器，而不必每次都重新创建整个 SELECT。

这也将逻辑放在一个单独的位置，这样您就不必在整个代码库中对其进行更改。

看看这个

选择存储过程，函数，视图，触发器，内联 SQL

一个景观的主要美丽之处在于 在大多数情况下可以像桌子一样使用 但不像桌子，它可以 封装非常复杂的计算 和常用的连接。它也可以 使用数据库中几乎所有的对象 存储过程除外。视图 在你需要的时候是最有用的 要加入同一组表，可以说 订单与订单细节得到 汇总计算字段等。

小开

(抄袭了谷歌搜索中出现的第一个教程(现在已经没有链接了) ，但是它具有所有的好处，如果是我的话，我会自己手动输入。)

意见有以下好处:

  • 安全性——当基础表不能直接访问时，用户可以访问视图。这允许 DBA 只向用户提供他们需要的数据，同时保护同一表中的其他数据。
  • 简单性-视图可用于隐藏和重用复杂查询。
  • 列名简化或澄清-视图可以用来为列名提供别名，使它们更容易记忆和/或更有意义。
  • 步骤石-视图可以在“多级”查询中提供步骤石。例如，可以创建一个查询视图，该视图计算每个销售人员的销售额。然后可以查询该视图，根据销售人员的销售数量对他们进行分组。
小开

视图允许您组合来自多个不同表的数据并对其进行格式化(组合字段，给出更有意义的字段名等) ，这样对于最终用户来说更加容易。它们是数据库模型的抽象。它们还可以用于让用户访问表中的数据，而无需让用户直接访问表本身。

小开

来自 维基百科的一些理由:

视图比表格更有优势:

  1. 视图可以表示表中包含的数据的子集
  2. 视图可以将多个表连接并简化为 单一虚拟表单一虚拟表
  3. 视图可以是数据库引擎聚合的 作为聚合表 数据(总和、平均等) ，并将计算结果作为数据的一部分
  4. 视图可以是 隐藏数据的复杂性; 例如，视图可以显示为 Sales2000或 Sales2001，透明地对实际的基础表进行分区
  5. 视图 储存空间很小; 数据库只包含 视图的定义，而不是它显示的所有数据的副本
  6. 视图可以 提供额外的安全保障，具体取决于所使用的 SQL 引擎
  7. 视图可以将一个或多个表的 限制暴露的程度传递给外部世界
小开

一小部分常见的原因/用途:

  • 使用它们来改变格式或 数据的‘ look’(也就是说，您可以加入一个 姓和名)

    执行计算或其他查找 数据

    反规范化数据(从中提取数据) 几张桌子放在一个地方)

小开
最佳答案

前面的答案似乎都没有提到的另一个用途是更容易部署表结构更改。

比如，您希望退出一个包含活动用户数据的表(T_OLD) ，而使用一个包含类似数据(名为 T_NEW)但同时包含活动用户和非活动用户数据的新表(多一列 active)。

如果您的系统有大量执行 SELECT whatever FROM T_OLD WHERE whatever的查询，那么您有两个选择来推出:

1) 冷血动物-更改数据库，同时更改、测试和发布包含上述查询的大量代码。非常难做(甚至协调) ，非常危险。很糟糕。

2) 循序渐进-通过创建 T_NEW表，删除 T_OLD表，而是创建一个名为 T_OLD的 视图来改变数据库，这个 视图100% 模仿 T_OLD表(例如视图查询是 SELECT all_fields_except_active FROM T_NEW WHERE active=1)。

这将允许您避免释放当前从 T_OLD选择的任何代码，并在空闲时更改将代码从 T_OLD迁移到 T_NEW。

这是一个简单的例子，还有其他更多的涉及。

另一方面，您可能应该使用 存储过程 API，而不是从 T_OLD直接查询，但情况并非总是如此。

小开

下面是使用视图根据某些标准约束实体的一种非常常见的用法。

表: USERS 包含所有用户

视图: Aactive _ USERS 包含所有用户，但不包括那些被暂停、禁止、等待激活且不符合将来作为活动需求一部分可能定义的任何标准的用户。这使得如果您选择不删除 USERS 表中的任何行，就没有必要这样做，因为 Aactive _ USERS 总是可以隐藏不需要的行。

这样，您可以在用户管理页面中使用该表，但应用程序的其余部分可以使用 AIVE _ USERS，因为它们可能是应该能够执行进程和访问/修改数据的唯一用户。

小开

视图是一个抽象层，它可以做任何好的抽象层所做的事情，包括封装数据库模式和保护您免受更改内部实现细节的影响。

这是个接口。

小开

意见是邪恶的！如果可能的话避免使用它们，并且只使用 DVK 提到的原因——临时数据迁移。

您应该明白，在一个有100个表的数据库中，很难记住每个表的用途。现在，如果你在这里添加另外300个浏览量，它将成为一个完全混乱。比“查看爱好者”更倾向于使用嵌套视图，然后在存储过程中使用嵌套视图。我个人现在的工作与一个数据库，其中有深度嵌套的视图4倍！ 因此，要理解存储过程的最简单逻辑，我必须首先浏览所有视图。

小开

以下是直接使用 view 而不是 table 的一些原因

  • 简单性-视图可以用来隐藏复杂的查询。
  • Security-View 可以通过在一些选定的列上创建视图来向最终用户隐藏一些重要信息
  • Security-使用 VIEW 更改表结构的安全表。
  • 冗余-使用公共视图减少每个过程/查询中的冗余代码。
  • 计算-所有的计算可以做一次在视图查询。
  • 有意义的名称-表可以有像 tbl _ org _ emp _ id 这样的 id 名称，它可以别名为[ Employee No ]或一些有意义的名称。

来自 探索网站


提交答案