【发布时间】:2010-11-19 16:41:05
【问题描述】:
某人何时以及为何决定需要在其数据库中创建视图?为什么不只运行一个普通的存储过程或选择?
【问题讨论】:
-
查看我的answer 是否有类似问题,希望对您有所帮助!
标签: sql sql-server database tsql
某人何时以及为何决定需要在其数据库中创建视图?为什么不只运行一个普通的存储过程或选择?
【问题讨论】:
标签: sql sql-server database tsql
视图提供多种好处。
1.视图可以隐藏复杂性
如果您的查询需要连接多个表,或者具有复杂的逻辑或计算,您可以将所有逻辑编码到一个视图中,然后像处理表一样从视图中进行选择。
2。视图可以用作安全机制
视图可以从一个(或多个表)中选择某些列和/或行,并在视图而不是基础表上设置权限。这允许仅显示用户需要查看的数据。
3.视图可以简化支持遗留代码
如果您需要重构会破坏大量代码的表,您可以使用同名视图替换该表。该视图提供与原始表完全相同的架构,而实际架构已更改。这样可以防止引用表的旧代码中断,让您可以在闲暇时更改旧代码。
这些只是视图如何发挥作用的众多示例中的一部分。
【讨论】:
出于安全考虑:仅允许每个用户通过包含用户或用户组有权查看的特定数据的一小组视图来访问数据库,从而限制用户访问其他数据.
查询和结构的简单性:一个视图可以从多个表中提取数据并呈现一个表,简化信息并将多表查询转换为视图的单表查询,它提供用户数据库结构的特定视图,将数据库呈现为一组特定于特定用户或用户组的虚拟表。
创建一致的数据库结构:视图呈现一致的、未更改的数据库结构图像,即使基础源表已更改。
【讨论】:
这里有两个常见的原因:
您可以使用它来确保安全。不授予对主表的权限,并创建限制列或行访问的视图,并授予用户查看视图的权限。
您可以使用它来方便。将您在视图中一直一起使用的一些表连接在一起。这可以使查询保持一致且更容易。
【讨论】:
它可以充当您的 ORM 和表之间的良好“中间人”。
例子:
我们有一个 Person 表,我们需要更改它的结构,以便将 SomeColumn 列移到另一个表中,并与之建立一对多的关系。
但是,对于 Person 来说,系统的大部分仍然使用 SomeColumn 作为一个单一的东西,而不是很多东西。我们使用视图将所有 SomeColumns 放在一起并将其放入视图中,效果很好。
这很有效,因为数据层发生了变化,但业务需求并没有从根本上改变,所以业务对象不需要改变。如果业务对象必须改变,我认为这不是一个可行的解决方案,但视图绝对是一个很好的中间点。
【讨论】:
视图相对于存储过程的一个主要优点是您可以像使用表一样使用视图。即,可以在查询的FROM 子句中直接引用视图。例如,SELECT * FROM dbo.name_of_view。
在几乎所有其他方面,存储过程都更强大。可以传入参数,包括out参数,可以有效的一次返回多个值,可以进行SELECT、INSERT、UPDATE、DELETE等操作。
如果您希望 View 能够从 FROM 子句中进行查询,但您还希望能够传入参数,那么也有一种方法可以做到这一点。它被称为表值函数。
这是一篇关于该主题的非常有用的文章:
编辑:顺便说一句,这提出了一个问题,与表值函数相比,视图有什么优势?我对此没有一个很好的答案,但我会注意到创建视图的 T-SQL 语法比表值函数更简单,并且数据库的用户可能更熟悉视图。
【讨论】:
专注于特定数据 视图允许用户专注于他们感兴趣的特定数据以及他们负责的特定任务。不必要的数据可以被排除在视图之外。这也增加了数据的安全性,因为用户只能看到视图中定义的数据,而不能看到基础表中的数据。有关出于安全目的使用视图的更多信息,请参阅将视图用作安全机制。
简化数据处理 视图可以简化用户操作数据的方式。您可以将常用的连接、投影、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
【讨论】:
几个原因: 如果您有复杂的连接,有时最好有一个视图,这样任何访问都将始终具有正确的连接,而开发人员不必记住他们可能需要的所有表。通常这可能适用于所有财务报告都基于相同数据集的财务应用程序。
如果您有用户想要限制他们可以看到的记录,您可以使用视图,让他们只访问视图而不是基础表,然后查询视图
Crystal 报告似乎更喜欢使用视图而不是存储过程,因此编写大量报告的人倾向于使用大量视图
视图在重构数据库时也非常有用。您通常可以通过创建视图来隐藏更改,以便旧代码看不到它。阅读重构数据库以了解其工作原理,因为它是一种非常强大的重构方式。
【讨论】:
我们创建视图来限制或限制访问表中的所有行/列。如果所有者希望只共享特定或有限的行/列,那么他将使用这些列创建视图。
【讨论】:
以下是如何使用视图以及权限来限制用户可以在表中更新的列。
/* 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
【讨论】:
我认为第一个。隐藏查询的复杂性。它非常适合视图。当我们规范化数据库表时如何增加。现在,当表数量增加时,获取数据非常困难。所以最好的处理方法是关注视图。如果我错了,请纠正我。
【讨论】:
我正在创建 xxx,它映射主表(如 Products 表)和引用表(如 ProductType 或 ProductDescriptionByLanguage)之间的所有关系。这将创建一个视图,允许我检索产品及其从外键转换为描述的所有详细信息。 然后我可以使用 ORM 创建对象来轻松构建网格、组合框等。
【讨论】:
我的生产数据库中只有 10 个左右的视图。我将几个用于我一直使用的列。我使用的一组来自 7 个表,其中一些带有外部连接,而不是不断地重写,我只需要在选择中调用该视图并进行一到两个连接。对我来说,这只是节省时间。
【讨论】:
一般来说,我使用视图让生活更轻松,从存储在多个表中的某些实体获取扩展详细信息(消除代码中的大量连接以增强可读性),有时在多个数据库上共享数据,甚至使插入更容易阅读。
【讨论】:
将其视为重构您的数据库架构。
【讨论】:
关于视图的一个奇怪之处在于它们被 Microsoft Access 视为表:当您使用 ODBC 将 Microsoft Access 前端连接到 SQL 数据库时,您会在可用表列表中看到表和视图。所以如果你在MS Access中准备复杂的报表,你可以让SQL服务器来做连接和查询,大大简化你的生活。在 MS Excel 中准备查询也是如此。
【讨论】:
我更多地将存储过程视为一种可以针对我的数据调用的方法,而对我而言,视图提供了一种机制来创建基础数据的合成版本,可以根据该版本创建查询或存储过程。当简化或聚合有意义时,我将创建一个视图。当我想提供非常具体的服务时,我会编写一个存储过程。
【讨论】:
我通常创建视图以对经常用于报告目的的数据进行非规范化和/或聚合。
编辑
通过详细说明,如果我有一个数据库,其中一些实体是人员、公司、角色、所有者类型、订单、订单详细信息、地址和电话,其中人员表存储员工和联系人以及地址和电话表存储个人和公司的电话号码,开发团队的任务是生成报告(或使非开发人员可以访问报告数据),例如员工销售额、客户销售额或地区销售额,按月销售、按州按客户等我将创建一组视图,这些视图对数据库实体之间的关系进行非规范化,以便提供对现实世界实体的更集成的视图(不是双关语)。一些好处可能包括:
【讨论】:
这并不能准确回答您的问题,但我认为值得一提的是物化视图。我的经验主要是Oracle,但据说 SQL-Server 非常相似。
我们在架构中使用了类似的东西来解决 XML 性能问题。我们的系统设计为将大量数据以 XML 形式存储在一行中,应用程序可能需要查询其中的特定值。处理大量 XMLType 和跨大量行运行 XPath 会对性能产生很大影响,因此我们使用一种具体化视图的形式在基表发生更改时将所需的 XML 节点提取到关系表中。这有效地提供了查询在某个时间点的物理快照,而不是按需运行查询的标准视图。
【讨论】:
视图还将非常复杂的配置和表分解为易于查询的可管理块。在我们的数据库中,我们的整个表管理系统被分解为一张大表的视图。
【讨论】:
在对遗留数据库进行报告时,视图可能是天赐之物。特别是,您可以使用有意义的表名而不是神秘的 5 个字母名称(其中 2 个是公共前缀!),或充满缩写的列名,我确信当时是有意义的。
【讨论】:
当我只运行查询时,我喜欢在存储过程上使用视图。视图还可以简化安全性,可用于简化对多个表的插入/更新,并可用于快照/物化数据(运行长时间运行的查询,并将结果缓存起来)。
我使用物化视图来运行不需要实时准确的长期查询。
【讨论】:
这样做的原因不止一个。有时使常见的连接查询变得容易,因为一个人可以只查询一个表名,而不是做所有的连接。
另一个原因是将数据限制为不同的用户。比如:
表 1:列 - USER_ID;USERNAME;SSN
管理员用户可以在实际表上拥有权限,但是您不想访问 SSN 的用户,您可以创建一个视图
CREATE VIEW USERNAMES AS SELECT user_id, username FROM Table1;然后授予他们访问视图而不是表的权限。
【讨论】:
除其他外,它还可用于安全性。如果您有一个“客户”表,您可能希望让所有销售人员都可以访问姓名、地址、邮政编码等字段,但不能访问 credit_card_number。您可以创建一个仅包含他们需要访问的列的视图,然后授予他们对该视图的访问权限。
【讨论】:
Select name, address, zipcode from customer 不会达到目的而不是 creating a view?
select * from customer,这使他们可以访问所有内容。如果您授予他们访问视图而不是表的权限,他们不能访问不在视图中的字段。
视图是查询的封装。转换为视图的查询往往很复杂,因此将它们保存为视图以供重用可能是有利的。
【讨论】:
当我想查看表的快照和/或视图(以只读方式)
【讨论】: