关于sql：可以有很多数据库视图吗？

我很少(每月/每季度)使用Microsoft SQL Server 2005数据库视图生成数百个Crystal Reports报表。 这些视图是否一直在浪费我的时间，而不是在浪费它们的CPU周期和RAM？ 由于我很少从视图中读取内容，我应该改为使用存储过程，临时表或短暂的普通表吗？

我不是DBA，所以我不知道数据库服务器内部幕后发生的事情。

是否有太多的数据库视图？ 什么是最佳做法？

在大多数情况下，这并不重要。是的，SQL Server解析SELECT * FROM table时将有更多选择(它必须在系统目录中查找" table")，但对此进行了高度优化，并提供了足够的RAM(当今大多数服务器都这样做) ，您不会注意到0到1,000次观看之间的差异。

但是，从人们的角度来看，试图管理和弄清楚"百"种视图在做什么是不可能的，因此您可能在那里有很多重复的代码。如果嵌入在这些冗余视图中的某些业务规则发生更改，会发生什么？

观点的主要观点是将业务逻辑封装到一个伪表中(因此您可能有一个人员表，但随后有一个称为" active_persons"的视图确实起到了神奇作用)。为每个报告创建视图是很愚蠢的，除非每个报告是如此孤立和独特，以至于无法重复使用。

视图是经常使用预设参数运行的查询。如果您知道您将一直在查看相同的数据，则可以创建一个易于使用和绑定数据的视图。

就是说，当您从视图中选择视图时，定义查询将与您正在运行的查询一起运行。

例如，如果vwCustomersWhoHavePaid为：

并且您正在运行的查询返回在8月1日之后付款的客户，其格式如下：

您实际正在运行的查询是：

创建视图时应牢记这一点，它们是存储您经常查看的数据的一种方式。这只是组织数据的一种方式，因此更易于访问。

您问：幕后发生了什么？

视图是一堆SQL文本。当查询使用视图时，SQL Server将该SQL文本放入查询中。这是在优化之前发生的。结果是优化器可以考虑合并的代码，而不是两个单独的代码段，以实现最佳执行计划。

您应该查看查询的执行计划！那里有很多东西要学习。

SQL Server还具有群集视图的概念。集群视图是系统维护的结果集(基础表上的每个插入/更新/删除都可能导致集群视图数据上的插入/更新/删除)。认为视图以集群视图的方式运行是一个常见的错误。

调用视图时，它们只会占用cpu /内存资源。

无论如何，最佳实践是合并可以合并的内容，删除可以删除的内容，并且如果字面意义仅由报表使用，请为视图选择一致的命名标准，以便在查找特定视图时可以轻松地将它们分组在一起。

另外，除非您确实需要事务隔离，否则请考虑在查询中使用NOLOCK表提示。

-凯文·费尔柴尔德(Kevin Fairchild)