2010-04-21 34 views

回答

57

另一个用途以前的答案似乎没有提到更容易部署表结构更改。假设您希望淘汰一个包含活跃用户数据的表(T_OLD),而是使用一个具有类似数据的新表(名为T_NEW),而另一个数据库为活动用户和非活动用户提供数据,并且有一个额外的列“活性”。

如果你的系统(S)具有极大数的查询做SELECT whatever FROM T_OLD WHERE whatever,你有转出两种选择:

1)冷土耳其 - 更改数据库,并在同一时间,变更,测试和释放包含所述查询的许多代码段。很难做(甚至协调),非常危险。坏。

2)渐进 - 通过创建T_NEW,滴T_OLD和而不是创建VIEW称为T_OLD模仿T_OLD表100%(例如视图查询是SELECT all_fields_except_active FROM T_NEW WHERE active=1)改变DB。

这样可以避免释放当前从T_OLD中选择的任何代码,并且执行更改以将代码从T_OLD迁移到T_NEW。

这是一个简单的例子,其他人涉及更多。

P.S.另一方面,你可能应该有一个存储过程API,而不是来自T_OLD的直接查询,但情况并非总是如此。

+0

哇..这真是一个很好的理由 – Luke101 2010-04-21 05:45:45

+0

非常好的一点! – David 2010-04-21 13:08:20

+2

我对术语“存储过程API”和相关的优点/缺点一无所知,并且发现这篇文章有用:http://www.codinghorror.com/blog/2005/05/stored-procedures-vs-ad-hoc-sql .html – 2013-12-13 01:31:05

13

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

这也将逻辑放在一个单一的位置,这样你就不必在整个代码基础上改变它。

看一看

Choice Between Stored Procedures, Functions, Views, Triggers, Inline SQL

视图的主要优点在于它 可以像在大多数 情况下,一台可以使用,但不同的表,它可以 封装非常复杂的计算 和常用连接。除存储过程外,它还可以使用db 中的几乎任何对象。查看 是最有用的,当你总是需要 加入同一组表的说,一个 订单与订单明细获得 汇总计算领域等

+0

+1的一个很好的答案 – David 2010-04-21 04:00:27

+6

必须非常小心这样做。如果您使用调用其他视图的视图,则可能会造成巨大的性能混乱。 – HLGEM 2011-09-10 16:10:32

34

(从first tutorial that came up in a Google search复制,但它拥有所有的好处我会手动键入自己)

意见有以下好处:

  • 安全 - 视图可以进行ACCE对于用户而言,底层表格不可直接访问。这允许DBA仅为用户提供所需的数据,同时保护同一表中的其他数据。
  • 简单 - 视图可以用来隐藏和重用复杂的查询。
  • 列名简化或澄清 - 可以使用视图在列名上提供别名,以使它们更易记忆和/或有意义。
  • 踏脚石 - 视图可以在“多级”查询中提供垫脚石。例如,您可以创建一个查询视图,计算每个销售人员的销售数量。然后,您可以查询该视图,按销售人员的销售数量对销售人员进行分组。
+0

因为我喜欢你的答案,并没有看到很多观点增加另一个,我可以给你的列表建议两个补充吗?索引视图可以提高性能。根据视图运行更新而不是直接到表可以给予更高的置信度,您不会错误地更新该关键生产表:) – 2010-04-21 04:11:06

+0

您的列表中还有一点,大多数DBA都希望使用视图,因为它们可以调整一个视图并主要并非总是)使用该视图的所有查询都将被调整。 – 2010-04-21 05:58:32

+0

这是我书中99%的答案。 – 2013-10-17 13:34:20

2

视图可以让您将数据从几个不同的表结合起来,对其进行格式化(结合领域,提供更多有意义的字段名等),因此,它是为最终用户更容易。它们是数据库模型的抽象。它们也可以用来让用户访问表中的数据,而不用直接访问表本身。

12

Wikipedia一些原因:

视图可以提供优于表优点:

  1. 视图可以表示包含在表中的数据的一个子集
  2. 视图可以加入并简化多个表变成单个虚拟表
  3. 查看可以充当聚合表,其中该数据库引擎聚集 数据(总和,平均值等),并提出了计算结果作为数据的一部分
  4. 视图可以隐藏数据的复杂性;例如一个视图可能显示为 Sales2000或Sales2001,透明地划分实际的基础表
  5. 视图占用很少的空间来存储;该数据库只包含 定义的视图,而不是所有的它呈现
  6. 根据所使用的SQL引擎的数据副本,视图可以提供额外的安全性
  7. 意见,可以限制的曝光程度一个或多个表的外部世界
1

的常见原因小清单/用途:

  • 使用它们瓒数据的“外观”(即“看”)格式或 。你可能会一起加入 姓和名)

    进行计算或其它查找 数据

    非规范化从 几个表中的数据(提取数据到一个点)

3

下面是使用视图来约束实体的一个非常常见的用法。

表:USERS包含所有用户

查看:ACTIVE_USERS包含所有用户,但不包括那些谁被暂停,禁止,等待被激活,不符合你可以选择在未来定义任何标准作为活动的一部分,要求。这样就不必删除USERS表中的任何行,因为ACTIVE_USERS总是可以隐藏不需要的行。

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

7

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

这是一个界面。

+0

好的角度。 – David 2010-04-21 13:09:07

+0

只要您不将堆叠视图进一步抽象。 – HLGEM 2011-09-10 16:10:58

+0

我想我已经有效地否定了关系数据库中的任何一种多级抽象。而且我也不会从存储过程调用存储过程。 :) – dkretz 2011-09-10 19:35:30

-1

观点是邪恶的!如果可能,尽量避免使用它们,并仅用于DVK提到的原因 - 临时数据迁移。

您应该明白,在具有100个表的数据库中,很难记住每个表的目的。现在,如果你在这里添加另外300个视图,它将变得完全混乱。比'查看爱好者'倾向于使用嵌套视图,然后使用存储过程中的嵌套视图。我personnaly现在与一个数据库,其中有4倍的视图嵌套深度! 因此,为了理解存储过程的最简单的逻辑,我必须首先查看所有视图。

+6

-1意见很好。如果你不恰当地使用它们,它们*会变成邪恶的 - 但对任何事情都是如此。 – NullUserException 2011-09-07 02:57:20

+1

如果使用不当,视图可能会变得邪恶。那些最常使用它们的人似乎是那些使用它们来抽象事物然后像你说的那样做的人,调用视图调用视图来调用视图,以便在返回结果之前可能需要实现1000万个recrod直接调用表的视图可能非常有用。 – HLGEM 2011-09-10 16:14:55

+0

@HGLEM有没有限制来自其他视图的视图调用的方法? – 2016-06-08 22:32:36

0

并非总是如此,您无法更新视图的基础表。

例如,尝试

创建视图theyshallnotpass如SELECT * FROM

,并在有一个讨厌的惊喜更新一次...

(MSSQL)

1

这里有使用视图而不是直接使用视图的一些原因

  • Simplicit y - 视图可以用来隐藏复杂的查询。
  • 安全性 - 查看可以通过在某些选定列上创建视图来隐藏最终用户的一些重要信息
  • 安全性 - 安全表,通过使用VIEW来更改其结构。
  • 冗余 - 通过使用通用视图减少每个过程/查询中的冗余代码。
  • 计算 - 所有计算都可以在查看查询中完成一次。
  • 有意义的名称 - 表可能具有名称,如tbl_org_emp_id,其名称可以是[员工编号]或一些有意义的名称。

imexploring.com

相关问题