我很少(每月/每季度)使用 Microsoft SQL Server 2005 数据库视图生成数百个 Crystal Reports 报告。这些视图是否在我不阅读它们的所有时间都在浪费 CPU 周期和 RAM?我应该改用存储过程、临时表还是短期普通表,因为我很少从视图中读取数据?
我不是 DBA,所以我不知道数据库服务器内部的幕后情况。
是否有可能有太多的数据库视图?什么是最佳实践?
我很少(每月/每季度)使用 Microsoft SQL Server 2005 数据库视图生成数百个 Crystal Reports 报告。这些视图是否在我不阅读它们的所有时间都在浪费 CPU 周期和 RAM?我应该改用存储过程、临时表还是短期普通表,因为我很少从视图中读取数据?
我不是 DBA,所以我不知道数据库服务器内部的幕后情况。
是否有可能有太多的数据库视图?什么是最佳实践?
在大多数情况下,这并不重要。是的,SQL Server 在解析 SELECT * FROM 表时会有更多选择(它必须在系统目录中查找“表”),但它为此进行了高度优化,并且只要您有足够的 RAM(现在大多数服务器都有) ,您不会注意到 0 和 1,000 次观看之间的差异。
但是,从人们的角度来看,试图管理和弄清楚“数百个”视图在做什么可能是不可能的,所以那里可能有很多重复的代码。如果嵌入在这些冗余视图中的某些业务规则发生变化会发生什么?
视图的主要观点是将业务逻辑封装到一个伪表中(因此您可能有一个人员表,但随后是一个名为“active_persons”的视图,它有一些魔力)。为每个报表创建视图有点愚蠢,除非每个报表都非常孤立和独特,以至于无法重用。
视图是您经常使用预设参数运行的查询。如果您知道您将一直查看相同的数据,您可以创建一个易于使用和数据绑定的视图。
话虽如此,当您从视图中选择时,定义查询的视图将与您正在运行的查询一起运行。
例如,如果 vwCustomersWhoHavePaid 是:
Select * from customers where paid = 1
并且您正在运行的查询返回在 8 月 1 日之后付款的客户,其格式如下:
Select * from vwCustomersWhoHavePaid where datepaid > '08/01/08'
您实际运行的查询是:
Select * from (Select * from customers where paid = 1) where datepaid > '08/01/08'
这是您在创建视图时应该记住的事情,它们是一种存储您经常查看的数据的方式。这只是一种组织数据的方式,因此更容易访问。
视图只会在调用时占用 CPU/内存资源。
无论如何,最佳实践是合并可以合并的内容,删除可以删除的内容,如果实际上仅由您的报告使用,请为视图选择一致的命名标准,以便在查找特定视图时可以轻松地将它们组合在一起.
此外,除非您确实需要事务隔离,否则请考虑在查询中使用 NOLOCK 表提示。
——凯文·费尔柴尔德
你问:幕后发生了什么?
视图是一堆 SQL 文本。当查询使用视图时,SQL Server 将该 SQL 文本放入查询中。这发生在优化之前。结果是优化器可以考虑组合代码而不是两段单独的代码以获得最佳执行计划。
您应该查看查询的执行计划!那里有很多东西要学。
SQL Server 也有一个集群视图的概念。集群视图是系统维护的结果集(基础表上的每个插入/更新/删除都可能导致集群视图数据的插入/更新/删除)。认为视图以集群视图的方式运行是一个常见的错误。