【问题标题】:Why do you create a View in a database?为什么要在数据库中创建视图?
【发布时间】:2010-11-19 16:41:05
【问题描述】:

某人何时以及为何决定需要在其数据库中创建视图?为什么不只运行一个普通的存储过程或选择?

【问题讨论】:

  • 查看我的answer 是否有类似问题,希望对您有所帮助!

标签: sql sql-server database tsql


【解决方案1】:

视图提供多种好处。

1.视图可以隐藏复杂性

如果您的查询需要连接多个表,或者具有复杂的逻辑或计算,您可以将所有逻辑编码到一个视图中,然后像处理表一样从视图中进行选择。

2。视图可以用作安全机制

视图可以从一个(或多个表)中选择某些列和/或行,并在视图而不是基础表上设置权限。这允许仅显示用户需要查看的数据。

3.视图可以简化支持遗留代码

如果您需要重构会破坏大量代码的表,您可以使用同名视图替换该表。该视图提供与原始表完全相同的架构,而实际架构已更改。这样可以防止引用表的旧代码中断,让您可以在闲暇时更改旧代码。

这些只是视图如何发挥作用的众多示例中的一部分。

【讨论】:

  • 第 3 项是其他人似乎还没有指出的原因
  • 我认为第 3 点更多的是权宜之计。最终,当您开始更新遗留代码时,您不仅需要更改视图背后的代码,还需要更改构建在视图之上的所有代码。我的 2cents
  • 3 确实是视图最强大的属性。这有助于提供逻辑数据独立性,您可以提供独立于底层逻辑数据库的数据库接口这一事实是一个非常强大的概念。
  • @John 这招致的技术债务迟早要还,不是吗? 10 年后,对于 10 年前编写它的工程师来说可能无关紧要,但对公司来说却很重要。
  • 更改您的主数据库以及依赖它的所有内容都是一个糟糕的选择,因为您可能“在 10 年内需要它”。技术债务不是不惜一切代价避免的,只有在以后修复它的预期成本高于现在修复它的确定成本时。
【解决方案2】:

出于安全考虑:仅允许每个用户通过包含用户或用户组有权查看的特定数据的一小组视图来访问数据库,从而限制用户访问其他数据.

查询和结构的简单性:一个视图可以从多个表中提取数据并呈现一个表,简化信息并将多表查询转换为视图的单表查询,它提供用户数据库结构的特定视图,将数据库呈现为一组特定于特定用户或用户组的虚拟表。

创建一致的数据库结构:视图呈现一致的、未更改的数据库结构图像,即使基础源表已更改。

【讨论】:

    【解决方案3】:

    这里有两个常见的原因:

    您可以使用它来确保安全。不授予对主表的权限,并创建限制列或行访问的视图,并授予用户查看视图的权限。

    您可以使用它来方便。将您在视图中一直一起使用的一些表连接在一起。这可以使查询保持一致且更容易。

    【讨论】:

      【解决方案4】:

      它可以充当您的 ORM 和表之间的良好“中间人”。

      例子:

      我们有一个 Person 表,我们需要更改它的结构,以便将 SomeColumn 列移到另一个表中,并与之建立一对多的关系。

      但是,对于 Person 来说,系统的大部分仍然使用 SomeColumn 作为一个单一的东西,而不是很多东西。我们使用视图将所有 SomeColumns 放在一起并将其放入视图中,效果很好。

      这很有效,因为数据层发生了变化,但业务需求并没有从根本上改变,所以业务对象不需要改变。如果业务对象必须改变,我认为这不是一个可行的解决方案,但视图绝对是一个很好的中间点。

      【讨论】:

      • 有趣。在您的情况下,它几乎就像表格的接口。
      【解决方案5】:

      视图相对于存储过程的一个主要优点是您可以像使用表一样使用视图。即,可以在查询的FROM 子句中直接引用视图。例如,SELECT * FROM dbo.name_of_view

      在几乎所有其他方面,存储过程都更强大。可以传入参数,包括out参数,可以有效的一次返回多个值,可以进行SELECTINSERTUPDATEDELETE等操作。

      如果您希望 View 能够从 FROM 子句中进行查询,但您还希望能够传入参数,那么也有一种方法可以做到这一点。它被称为表值函数。

      这是一篇关于该主题的非常有用的文章:

      http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html

      编辑:顺便说一句,这提出了一个问题,与表值函数相比,视图有什么优势?我对此没有一个很好的答案,但我会注意到创建视图的 T-SQL 语法比表值函数更简单,并且数据库的用户可能更熟悉视图。

      【讨论】:

      • +1 是解决针对 SELECT 语句的存储过程问题的少数答案之一。你提出表函数的问题是对的。基本上,视图可能比函数执行得更好,因为它们共享相同的引擎。从 SQL 切换到 trabsactional SQL(即 PL/SQL)时需要支付开销(至少在 Oracle 中)。但是所有其他的东西——安全、封装等——同样适用于过程或函数,也适用于视图。
      • 根据视图的结构,有些视图可以被索引。这是对表值函数的重大改进。
      【解决方案6】:

      专注于特定数据 视图允许用户专注于他们感兴趣的特定数据以及他们负责的特定任务。不必要的数据可以被排除在视图之外。这也增加了数据的安全性,因为用户只能看到视图中定义的数据,而不能看到基础表中的数据。有关出于安全目的使用视图的更多信息,请参阅将视图用作安全机制。

      简化数据处理 视图可以简化用户操作数据的方式。您可以将常用的连接、投影、UNION 查询和 SELECT 查询定义为视图,这样用户就不必在每次对该数据执行附加操作时指定所有条件和限定条件。例如,用于报告目的并执行子查询、外部连接和聚合以从一组表中检索数据的复杂查询可以创建为视图。该视图简化了对数据的访问,因为不必在每次生成报告时都编写或提交基础查询;而是查询视图。有关操作数据的更多信息。

      您还可以创建在逻辑上作为参数化视图或在 WHERE 子句搜索条件中具有参数的视图的内联用户定义函数。有关详细信息,请参阅内联用户定义函数。

      自定义数据 视图允许不同的用户以不同的方式查看数据,即使他们同时使用相同的数据。当具有许多不同兴趣和技能水平的用户共享同一个数据库时,这尤其有利。例如,可以创建一个视图,该视图仅检索与客户经理打交道的客户的数据。视图可以根据使用该视图的客户经理的登录 ID 确定要检索哪些数据。

      导出和导入数据 视图可用于将数据导出到其他应用程序。例如,您可能希望使用 pubs 数据库中的商店和销售表来使用 Microsoft® Excel 分析销售数据。为此,您可以创建基于商店和销售表的视图。然后,您可以使用 bcp 实用程序导出视图定义的数据。也可以使用 bcp 实用程序或 BULK INSERT 语句将数据从数据文件导入到某些视图中,前提是可以使用 INSERT 语句将行插入到视图中。有关将数据复制到视图中的限制的更多信息,请参阅 INSERT。有关使用 bcp 实用程序和 BULK INSERT 语句将数据复制到视图和从视图复制数据的详细信息,请参阅复制到视图或从视图复制。

      合并分区数据 Transact-SQL UNION 集运算符可在视图中使用,以将来自不同表的两个或多个查询的结果组合成一个结果集。这在用户看来是一个称为分区视图的表。例如,如果一个表包含华盛顿的销售数据,而另一个表包含加利福尼亚的销售数据,则可以从这些表的 UNION 创建一个视图。该视图代表两个地区的销售数据。 要使用分区视图,您需要创建几个相同的表,并指定一个约束来确定可以添加到每个表的数据范围。然后使用这些基表创建视图。查询视图时,SQL Server 会自动确定哪些表受查询影响并仅引用这些表。例如,如果查询指定只需要华盛顿州的销售数据,SQL Server 只读取包含华盛顿销售数据的表;没有其他表被访问。

      分区视图可以基于来自多个异构源(例如远程服务器)的数据,而不仅仅是同一数据库中的表。例如,要合并来自不同远程服务器的数据,每个远程服务器都为组织的不同区域存储数据,您可以创建从每个数据源检索数据的分布式查询,然后基于这些分布式查询创建视图。任何查询都只从远程服务器上包含查询请求的数据的表中读取数据;视图中分布式查询引用的其他服务器不被访问。

      当您跨多个表或多个服务器对数据进行分区时,仅访问一小部分数据的查询可以运行得更快,因为要扫描的数据更少。如果表位于不同的服务器上,或者位于多处理器的计算机上,则查询中涉及的每个表也可以并行扫描,从而提高查询性能。此外,维护任务(例如重建索引或备份表)可以更快地执行。 通过使用分区视图,数据仍然显示为单个表,并且可以按原样查询,而无需手动引用正确的基础表。

      如果满足以下任一条件,则分区视图是可更新的: 在视图上定义了一个 INSTEAD OF 触发器,其逻辑支持 INSERT、UPDATE 和 DELETE 语句。

      视图和 INSERT、UPDATE 和 DELETE 语句都遵循为可更新分区视图定义的规则。有关详细信息,请参阅创建分区视图。

      https://technet.microsoft.com/en-us/library/aa214282(v=sql.80).aspx#sql:join

      【讨论】:

      • 我必须说我在这里学到了一些东西。 “合并分区数据”是我不知道的,即使性能是一个很好的好处。如果您正确构建这些分区表,那将是一个完美的改进。
      • 我还想指出,这些信息来自一个 SQL2000 源,该源不再以网页形式提供,除了来自 Microsoft 的具有 20k 页的旧版可下载 PDF(按照帖子中的链接上面下载它)。第 1139 页“使用视图的场景”
      【解决方案7】:

      几个原因: 如果您有复杂的连接,有时最好有一个视图,这样任何访问都将始终具有正确的连接,而开发人员不必记住他们可能需要的所有表。通常这可能适用于所有财务报告都基于相同数据集的财务应用程序。

      如果您有用户想要限制他们可以看到的记录,您可以使用视图,让他们只访问视图而不是基础表,然后查询视图

      Crystal 报告似乎更喜欢使用视图而不是存储过程,因此编写大量报告的人倾向于使用大量视图

      视图在重构数据库时也非常有用。您通常可以通过创建视图来隐藏更改,以便旧代码看不到它。阅读重构数据库以了解其工作原理,因为它是一种非常强大的重构方式。

      【讨论】:

        【解决方案8】:

        我们创建视图来限制或限制访问表中的所有行/列。如果所有者希望只共享特定或有限的行/列,那么他将使用这些列创建视图。

        【讨论】:

        • 这只是您应该/可以使用视图的原因之一。
        【解决方案9】:

        以下是如何使用视图以及权限来限制用户可以在表中更新的列。

        /* 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
        

        【讨论】:

          【解决方案10】:

          我认为第一个。隐藏查询的复杂性。它非常适合视图。当我们规范化数据库表时如何增加。现在,当表数量增加时,获取数据非常困难。所以最好的处理方法是关注视图。如果我错了,请纠正我。

          【讨论】:

          • 如果你用谷歌搜索,你会得到这个问题的非常清楚的信息。
          【解决方案11】:

          我正在创建 xxx,它映射主表(如 Products 表)和引用表(如 ProductType 或 ProductDescriptionByLanguage)之间的所有关系。这将创建一个视图,允许我检索产品及其从外键转换为描述的所有详细信息。 然后我可以使用 ORM 创建对象来轻松构建网格、组合框等。

          【讨论】:

            【解决方案12】:

            我的生产数据库中只有 10 个左右的视图。我将几个用于我一直使用的列。我使用的一组来自 7 个表,其中一些带有外部连接,而不是不断地重写,我只需要在选择中调用该视图并进行一到两个连接。对我来说,这只是节省时间。

            【讨论】:

            • 如果这超出了问题的范围,请原谅我,但有几个人提到了这一点 - 你这样做不会招致某种性能损失吗?
            • 一点也不。 SQL Server 优化器显示从视图中选择 * 的计划与对等效于视图的 SQL 连接所做的计划完全相同
            【解决方案13】:

            一般来说,我使用视图让生活更轻松,从存储在多个表中的某些实体获取扩展详细信息(消除代码中的大量连接以增强可读性),有时在多个数据库上共享数据,甚至使插入更容易阅读。

            【讨论】:

              【解决方案14】:

              将其视为重构您的数据库架构。

              【讨论】:

                【解决方案15】:

                关于视图的一个奇怪之处在于它们被 Microsoft Access 视为表:当您使用 ODBC 将 Microsoft Access 前端连接到 SQL 数据库时,您会在可用表列表中看到表和视图。所以如果你在MS Access中准备复杂的报表,你可以让SQL服务器来做连接和查询,大大简化你的生活。在 MS Excel 中准备查询也是如此。

                【讨论】:

                  【解决方案16】:

                  我更多地将存储过程视为一种可以针对我的数据调用的方法,而对我而言,视图提供了一种机制来创建基础数据的合成版本,可以根据该版本创建查询或存储过程。当简化或聚合有意义时,我将创建一个视图。当我想提供非常具体的服务时,我会编写一个存储过程。

                  【讨论】:

                  • 能否举个小服务的例子
                  【解决方案17】:

                  我通常创建视图以对经常用于报告目的的数据进行非规范化和/或聚合。

                  编辑

                  通过详细说明,如果我有一个数据库,其中一些实体是人员、公司、角色、所有者类型、订单、订单详细信息、地址和电话,其中人员表存储员工和联系人以及地址和电话表存储个人和公司的电话号码,开发团队的任务是生成报告(或使非开发人员可以访问报告数据),例如员工销售额、客户销售额或地区销售额,按月销售、按州按客户等我将创建一组视图,这些视图对数据库实体之间的关系进行非规范化,以便提供对现实世界实体的更集成的视图(不是双关语)。一些好处可能包括:

                  1. 减少编写查询的冗余
                  2. 为相关实体建立标准
                  3. 提供机会 评估和最大化绩效 用于复杂的计算和连接 (例如,在 Schemabound 视图上建立索引 在 MSSQL 中)
                  4. 使数据更易于访问和 对团队成员和非开发人员来说直观。

                  【讨论】:

                  • 你能详细说明一下吗?你的答案被投票了很多,但我没有得到其他人似乎的价值
                  【解决方案18】:

                  这并不能准确回答您的问题,但我认为值得一提的是物化视图。我的经验主要是Oracle,但据说 SQL-Server 非常相似。

                  我们在架构中使用了类似的东西来解决 XML 性能问题。我们的系统设计为将大量数据以 XML 形式存储在一行中,应用程序可能需要查询其中的特定值。处理大量 XMLType 和跨大量行运行 XPath 会对性能产生很大影响,因此我们使用一种具体化视图的形式在基表发生更改时将所需的 XML 节点提取到关系表中。这有效地提供了查询在某个时间点的物理快照,而不是按需运行查询的标准视图。

                  【讨论】:

                    【解决方案19】:

                    视图还将非常复杂的配置和表分解为易于查询的可管理块。在我们的数据库中,我们的整个表管理系统被分解为一张大表的视图。

                    【讨论】:

                      【解决方案20】:

                      在对遗留数据库进行报告时,视图可能是天赐之物。特别是,您可以使用有意义的表名而不是神秘的 5 个字母名称(其中 2 个是公共前缀!),或充满缩写的列名,我确信当时是有意义的。

                      【讨论】:

                        【解决方案21】:

                        当我只运行查询时,我喜欢在存储过程上使用视图。视图还可以简化安全性,可用于简化对多个表的插入/更新,并可用于快照/物化数据(运行长时间运行的查询,并将结果缓存起来)。

                        我使用物化视图来运行不需要实时准确的长期查询。

                        【讨论】:

                        • 当你运行一个查询而不是?为什么?这一点不太合理
                        • 当您使用视图时,您知道您只是在执行 DML 操作,当您调用 SP 时,您不会在获取数据之前发生其他可能发生的事情。 IE。调用缓存函数,可能会返回缓存的数据集,但这并不意味着您应该调用 SP 所需的所有数据。它简化了数据 IMO 的 API
                        【解决方案22】:

                        这样做的原因不止一个。有时使常见的连接查询变得容易,因为一个人可以只查询一个表名,而不是做所有的连接。

                        另一个原因是将数据限制为不同的用户。比如:

                        表 1:列 - USER_ID;USERNAME;SSN

                        管理员用户可以在实际表上拥有权限,但是您不想访问 SSN 的用户,您可以创建一个视图

                        CREATE VIEW USERNAMES AS SELECT user_id, username FROM Table1;

                        然后授予他们访问视图而不是表的权限。

                        【讨论】:

                          【解决方案23】:

                          除其他外,它还可用于安全性。如果您有一个“客户”表,您可能希望让所有销售人员都可以访问姓名、地址、邮政编码等字段,但不能访问 credit_card_number。您可以创建一个仅包含他们需要访问的列的视图,然后授予他们对该视图的访问权限。

                          【讨论】:

                          • 有趣。安全是一个很好的答案。你有什么“其他事情”?
                          • 我认为这个问题的其他答案将描述“其他事物”。 :-)
                          • Select name, address, zipcode from customer 不会达到目的而不是 creating a view?
                          • @PranavBilurkar 是的,如果您完全控制用户运行的查询。如果用户能够运行自己的查询(通过一些交互式 SQL 程序或编写自己的脚本),他们可以运行select * from customer,这使他们可以访问所有内容。如果您授予他们访问视图而不是表的权限,他们不能访问不在视图中的字段。
                          【解决方案24】:

                          视图是查询的封装。转换为视图的查询往往很复杂,因此将它们保存为视图以供重用可能是有利的。

                          【讨论】:

                          • 那么当您有一个复杂的查询时,您会想要创建一个视图吗?查询有多复杂,阈值是多少?把它变成一个视图,你有什么收获?
                          • 个人选择到底有多复杂,没有设定的门槛。例如,如果您不想在多个应用程序或应用程序中的不同点中复制逻辑,您通常会使用视图。通过将其设为视图,您可以隐藏该逻辑并能够轻松共享它。
                          • 你不能对有选择的存储过程做同样的事情吗?我是否错误地将存储过程视为存储复杂查询逻辑的一种方式?复杂的查询应该在视图而不是存储过程中完成吗?存储过程在这里有什么好处?
                          • @MedicineMan - 存储过程返回结果集,而视图表示虚拟表,允许您在其他查询中用作表。
                          • 我觉得关于结果集 vs 虚拟表的这一点似乎是我没有理解的关键点。
                          【解决方案25】:

                          当我想查看表的快照和/或视图(以只读方式)

                          【讨论】:

                          • “表格快照”是什么意思?您何时或为什么要这样做?
                          • 场景很多;假设您想在表上运行复杂的查询/存储过程而不影响和下划线表。您创建一个视图(只读表示)
                          • 所以如果你想运行一个复杂的查询存储过程,你不能以只读方式访问视图吗?我真的没有数据库经验来“获取”您在这里谈论的内容。您能否详细说明或提供详细示例?
                          猜你喜欢
                          • 2019-02-21
                          • 1970-01-01
                          • 1970-01-01
                          • 1970-01-01
                          • 1970-01-01
                          • 2011-01-28
                          • 2014-09-09
                          • 2021-06-05
                          • 1970-01-01
                          相关资源
                          最近更新 更多