Sql Server 2008嵌套视图

是否有关于是否使用嵌套视图的一般最佳实践？使用嵌套视图是否会影响性能？有没有一个最佳实践表明，只有深入到4层或更多层，性能才会受到影响

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

---

然而，这也许不是一个好的做法。你介意分享一下你的想法吗？

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

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

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

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

分析-例如分组集

程序和临时表-通过程序将所需数据写入临时表，从临时表中选择

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

---

通常，您可以使用表之间的正确联接生成一个视图，该联接包含您的所有信息，并使用条件筛选出数据。

视图是否进行聚合？是否要将同一个基表连接到自身？看看执行计划，看看你是否得到了次优的计划。你能提供一个嵌套视图的例子吗？我只熟悉以下术语：内联视图又名派生表、非物化视图和物化视图又名SQL Server中的索引视图。@OMG-我把它理解为引用其他视图的视图，而引用其他视图的视图…@Martin:分层视图？那太糟糕了/我向马丁挥了挥手，我想这就是我的意思。。。引用其他视图的视图。现在，我正在查看执行计划，我将从嵌套视图中退出，看看哪些索引视图可能有助于仅使用一层深度。+1 SQL是一种情况，在这种情况下，重复自己以避免嵌套视图是合适的。优化器可以在嵌套视图中使用索引，除非视图逻辑复杂且复杂模糊索引。索引视图提出了一组不同的问题，但对于执行简单联接的普通视图，嵌套并不会阻止优化器使用索引。我的意思是，您不能在视图上创建索引，也不是说它们不能使用基础索引。但是，您可能很快就会到达优化器无法找到如何有效处理此问题的地步。不仅如此，它们很快就变成了无法维持的烂摊子。这是一种SQL反模式，如果可能的话应该避免，而且几乎总是可能的。视图可用于捕获在多个级别重复需要的连接关系。例如，我有一个市场表。每个市场都属于一个部门，所以我也有一个部门表，市场表有一个带有适当外键的部门ID。每个扇区都属于一个MacroSector，所以我还有一个MacroSector表，扇区表有一个带有适当外键的MacroSector ID。现在，如果我告诉你，许多使用市场的东西也需要部门和宏观部门，你真的要几十次重写相同的连接关系吗？这是一个复杂的问题，视图可能会导致数据库做额外的工作，这比开发人员必须编写几个连接要重要得多。如果嵌套视图，则视图不是一种好的做法。您可能会遇到严重的麻烦。有关索引视图的问题。是否需要显式指定视图，或者优化器是否会选择索引视图，即使

---

u将访问一些基表，但在执行路径中，它决定了视图更好。因此，我发现了这个答案：视图不需要在查询中直接引用，优化器才能在查询执行计划中使用它。@用户-取决于版本。这仅在Enterprise and Developer edition中发生，否则需要显式引用视图并使用noexpand提示。