什么是好的意见?

我只是想了解在RDBMS中使用哪些视图的一般概念。 也就是说,我知道什么是一个观点,以及如何制定一个观点。 我也知道我以前用过他们的东西。

但是,我想确保我对透视有什么用处,以及哪些视图不适用的透彻理解。 进一步来说:

  1. 什么是有用的视图?
    • 在不应该使用视图的情况下,有没有什么情况可以使用视图?
    • 你为什么要用一个视图来替代表值函数,反之亦然?
    • 有没有任何情况下,一看起来可能是有用的,乍一看是不明显的?

(logging下来,其中一些问题是故意天真的,这部分是概念检查。)

1)什么是有用的视图?

IOPO只在一个地方

•无论您考虑数据本身还是引用连接表的查询,都可以使用视图避免不必要的冗余。

•视图还提供一个抽象层,防止直接访问表(以及由此产生的涉及物理依赖关系的手铐)。 实际上,我认为最好的做法是只提供对基础数据的抽象访问(使用视图和表值函数),包括视图

CREATE VIEW AS
SELECT * FROM tblData

1我承认在这个build议中有很多“按我说的做,不如我做”;)

2)在不使用视图的情况下,有没有什么情况可以使用视图?

性能视图连接曾经是一个问题(例如SQL 2000)。 我不是专家,但是我暂时不担心。 (我也不能想到我目前使用视图连接的位置。)

视图可能会过度的另一种情况是只能从一个调用位置引用视图,而可以使用派生表。 就像匿名types优于.NET中的类一样,如果匿名types只被使用/引用一次。

•请参阅http://msdn.microsoft.com/en-us/library/ms177634.aspx中的派生表说明;

3)为什么要用一个视图来代替表值函数,反之亦然?

(除了性能原因)表值函数在function上等同于参数化视图。 实际上,一个普通简单的表值函数用例就是简单地将WHERE子句filter添加到单个对象中已经存在的视图中。

4)有没有什么情况可能是有用的,乍一看并不明显?

我想不出我的头顶有什么不明显的用处。 (我想如果可以的话,那会使他们显而易见)

在某种程度上,视图就像一个界面。 您可以根据需要更改基础表结构,但视图为代码提供了一种不必更改的方法。

视图是向报告作者提供简单的一种很好的方式。 如果您的业务用户想要从Crystal Reports之类的数据访问数据,您可以在他们的帐户中给他们一些简化数据的视图 – 甚至可以为他们规范化数据。

视图可以用来提供安全性(即:用户可以访问只能访问表中的某些列的视图),视图可以为更新,插入等提供额外的安全性。视图还提供了别名列名的方法sp),但意见更多的是从实际的表中孤立。

从某种意义上来看,反规范化。 非规范化有时需要以更有意义的方式提供数据。 这是很多应用程序通过在对象中进行域build模的方式。 他们帮助用更贴近企业视angular的方式呈现数据。

视图隐藏数据库的复杂性。 它们有很多原因,在许多情况下都很有用,但是如果你有允许用户写自己的查询和报告的用户,你可以把它们作为一种安全措施,以确保它们不会提交错误的devise查询与令人讨厌的笛卡尔联接,取消您的数据库服务器。

除了其他人所说的外,视图也可以用于从应用程序中删除更多的复杂的SQL查询。

作为一个例子,而不是在一个应用程序中执行:

sql =“select a,b from table1 union select a,b from table2”;

你可以抽象出一个视图:

创build视图union_table1_table2_v为
从table1中selecta,b
联盟
从table2中selecta,b

并在应用程序代码中,只需拥有:

sql =“select a,b from union_table1_table2_v”;

另外,如果数据结构发生变化,则不必更改应用程序代码,重新编译和重新部署。 你只需要改变数据库中的视图。

OP询问是否存在可能使用视图的诱惑,但这不合适。

你不想使用视图是复杂连接的替代。 也就是说,不要让程序编程习惯将问题分解成小块,这会导致您使用多个视图连接在一起而不是一个较大的连接。 这样做会杀死数据库引擎的效率,因为它本质上是在做几个单独的查询而不是一个大的查询。

例如,假设您必须将表A,B,C和D连接在一起。 你可能会试图从表A和B中看出来,并从C&D中看出一个观点,然后把这两个观点结合在一起。 在一个查询中joinA,B,C和D会好得多。

视图可以集中或合并数据。 我在哪里我们有几个不同的链接服务器上的不同数据库。 每个数据库保存不同应用程序的数据。 这些数据库中的一些拥有涉及许多不同应用程序的信息。 在这种情况下我们要做的是在该应用程序的数据库中创build一个视图,从数据库中真正存储数据,以便我们编写的查询看起来不像跨越不同的数据库。

到目前为止的回应是正确的 – 视图对于提供安全性,非规范化是很好的(尽pipe如果做错了,那么这个道路有很多痛苦),数据模型抽象等等。

另外,视图通常用于实现业务逻辑(失效用户是在过去40天内没有login的用户,诸如此类的事情)。

视图在你的SQL脚本中保存了很多重复的JOIN语句。 您可以在某个视图中封装一些复杂的JOIN,并在需要时在您的SELECT语句中调用它。 这有时会比在每个查询中写出连接语句方便,直接和容易。

一个视图只是一个存储的,命名的SELECT语句。 考虑像库函数这样的观点。

我想强调报告的使用意见。 通常,在规范化数据库表以提高性能(尤其是编辑和插入数据(OLTP使用))和反规范化以减less用于报告和分析(OLAP使用)的查询的表连接数量之间存在冲突。 OLTP通常会赢得胜利,因为数据录入必须具有最佳性能。 然后创build视图,以获得最佳的报告性能,可以帮助满足这两类用户(数据input和报告查看者)。

我记得有一个很长的SELECT,涉及到几个UNION。 每个UNION都包含一个join价格表的function,这个function表是由一个SELECT自己创build的,它本身相当长,很难理解。 我认为创build价格表是一个好主意。 它将整个SELECT缩短了大约一半。

我不知道数据库是否会评估一次,或每次被调用一次。 有人知道吗? 如果前者使用视图会提高性能。

任何时候你需要[my_interface]!= [user_interface]。

例:

表A:

  • ID
  • 信息

查看表A:

  • 客户信息

这是一种可以隐藏客户身份的方法,并且一次将信息重命名为更加详细的名称。

该视图将使用主键id的基础索引,所以你不会看到性能损失,只是select查询的更好的抽象。