Sql Server 2008 嵌套视图答案

【问题标题】：Sql Server 2008 Nesting ViewsSql Server 2008 嵌套视图
【发布时间】：2011-08-20 07:36:22
【问题描述】：

是否有关于是否使用嵌套视图的一般最佳做法？使用嵌套视图时是否会影响性能？是否有最佳实践表明在您深入 4 层或更多层之前确实不会影响性能？

我问这个的原因是因为我正在为是否使用它们而苦苦挣扎。获得报告请求的情况并不罕见，我可以访问该信息的唯一方法是将 20 个或更多表连接在一起。并非所有表都返回字段，但需要选择正确的数据。在这种情况下，我喜欢嵌套视图并为其他报告重用较低级别的视图，因为如果需要更改逻辑，我只需更新一个视图并更新所有报告。我使用的许多表都包含数百万条记录。

但是，这可能不是一个好习惯。您介意分享您对此的看法吗？

【问题讨论】：

视图做聚合吗？您是否将同一个基表连接到自身？查看执行计划，看看您是否获得了次优计划。
你能提供一个“嵌套视图”的例子吗？我只熟悉以下术语：内联视图（AKA 派生表）、非物化视图和物化视图（SQL Server 中的 AKA 索引视图）。
@OMG - 我认为它是指引用其他视图的视图引用其他视图...
@Martin：分层视图？这很糟糕...... /me 对 Martin 挥手，我想是 OP
是的，这就是我的意思...引用其他视图的视图。现在我正在审查执行计划，我将退出嵌套视图，并查看哪些索引视图可能有助于仅深入一层。

标签： sql sql-server sql-server-2008 view

【解决方案1】：

要考虑的其他选项： 索引视图 -- 如果使用不当，使用起来可能很危险，但性能提升可能非常惊人。

分析——例如分组集

过程和临时表 -- 通过过程获取您需要的数据，将其写入临时表，从临时表中选择。

总的来说，我不喜欢视图上视图或嵌套视图对性能的影响。

通常，您可以使用表之间的正确连接来生成一个视图，其中包含您之后的所有信息，并使用标准过滤掉数据。

【讨论】：

关于索引视图的问题。是否需要显式指定视图，或者优化器是否会选择索引视图，即使您要访问某些基表但在执行路径中它会确定视图更好。
所以我找到了这个答案不需要在查询中直接引用视图，优化器就可以在查询执行计划中使用它。
@user - 取决于版本。这仅在 Enterprise 和 Developer 版本中发生，否则您需要明确引用视图并使用 noexpand 提示。

【解决方案2】：

我会不惜一切代价避免这种情况。首先，一旦嵌套视图，它们就不能被索引。接下来，因为它们必须完全实现底层视图才能进入下一层。因此，您可能会具体化数百万条记录以获得 5 条记录的最终结果。我们几乎失去了一个价值数百万美元的客户，因为当我们的开发人员在一个数据库（不是我在设计中输入的数据库）上执行此操作时性能非常糟糕。

最后，我发现当您需要进行更改时，这些类型的层很难维护。跟踪 12 层视图以找到需要修复的视图并不有趣。我们还遇到了一个问题，因为开发人员发现添加另一层比修复底层更容易，然后尝试在一个查询中访问太多表，而这些表中有太多是被访问的同一个数百万记录表在不同层的视图中 7 或 8 次。

在任何情况下，我都不允许在我管理的数据库中的视图中包含多个图层，如果你这样做我会很生气。

【讨论】：

+1 SQL 是一种适当的重复自己以避免嵌套视图的情况。
优化器可以在嵌套视图中使用索引，除非视图逻辑很复杂并且隐藏了索引。索引视图呈现出一组不同的问题，但对于执行简单连接的普通视图，嵌套不会阻止优化器使用索引。
我的意思是你不能在视图上创建索引，而不是它们不能使用底层索引。但是，您可以很快到达优化器无法弄清楚如何有效处理此问题的地步。不仅如此，它们很快就变成了无法维护的烂摊子。这是一种 SQL 反模式，应尽可能避免，而且几乎总是可能的。
视图可用于捕获在多个级别重复需要的连接关系。例如，我有一个市场表。每个市场都属于一个扇区，所以我也有一个扇区表，而市场表有一个带有适当外键的 SectorId。每个扇区都属于一个 MacroSector，所以我也有一个 MacroSector 表，并且 Sector 表有一个带有适当外键的 MacroSectorId。现在，如果我告诉你，很多使用市场的东西也需要扇区和宏观扇区，你真的要重写几十次相同的加入关系吗？那是一团糟
视图会导致数据库做额外的工作，这比开发人员编写几个连接要重要得多。如果嵌套视图，视图不是一个好习惯。你可能会遇到严重的麻烦。