SQL Server - 将复杂视图转换为表 - 最好的方法

Question

我正在构建的视图每周都变得越来越复杂和大。它的想法是拥有多个管理报告的来源，包括其中一些人进行的临时查询（会计师 - 我能说什么）。我不担心服务器上的负载 - 这个服务器专门用于此，所以需要一段时间才能使用任何重要的资源。但是在它上面做任何事情都需要越来越长的时间。

它大约有 30% 的计算字段，目前有 25 个连接，我可以删除其中的 8 个，但在某些时候会添加更多。无法对其进行索引，因为它跨越 4 个不同的数据库（目前），因此性能充其量只是龟龟。

所以我想按计划将视图的内容转储到表中，问题是：有没有更好的方法？如果没有，需要注意哪些障碍？

编辑：数据过时：直到前一天。数据范围：所有行，不幸的是，当前计数为 320 万。此外，还有开发阶段的问题——现在我们正在研究我们需要、想要和想要的东西，所以性能调整是毫无意义的 ATT。索引将是一个好的开始，但不是现在这个观点。拆分为多个视图/查询听起来不错，但不会从任何有意义的意义上减少执行时间（减少 20 分钟听起来很棒，直到您意识到起点是 75 分钟）。

我正在使用的数据已通过 SSIS 包从其他数据库（和服务器）复制。对其进行改造以将数据整合到一个数据库中可能是可行的，但这不是我的权限。这可能涉及财务成本，并且在所有开发工作完成之前将被管理层拒绝。

我只知道我需要大大加快速度。可能很脏。除非我会花更多的时间等待查询执行而不是适当的开发。

Answer 1

我认为这里的主要问题是您试图使用单个视图来提供许多不同的报告，从而使视图定义一遍又一遍地复杂化。

并非所有报告都需要JOIN该视图中的所有列、计算和s，因此，在许多情况下，您将无缘无故地点击表格并执行计算。

更明智的方法是对每个报告进行单独的优化查询，并使用最少的表。我知道这听起来像是很多工作，但是在不牺牲性能的情况下，在 T-SQL 中实现代码重用真的很难。

也就是说，如果您的所有报告都基于或多或少相同的数据，索引视图或物化中间表可能是一个可行的解决方案。索引视图有一些限制，使它们在某些情况下不切实际（没有自联接、没有外联接、没有UNIONs 等），并且可能会引入不可接受的写入开销，但如果使用得当，它们确实很强大。

Answer 2

因此，虽然定期将视图的结果转储到表中可能很容易（并且可能值得测试，如果您已经构建了其他所有内容），我建议从当前的源表中提取（过滤）行将多个数据库分散到一个数据库中，并从这些数据库中构建您的新视图。

好处：

• 您可以排除那些大型源表的列或行，或者在复制数据时进行计算/汇总
• 您可以向临时表添加适当的索引，专门为视图/查询/报告制作，而不会影响其他系统
• 由于所有表都在同一个数据库中，您可以创建索引视图（假设其他禁令不适用）
• 您可以在复制数据时进行一些基本的连接/查找，以减少最终查询或查询中连接的表的总数

缺点：

• 您必须弄清楚如何使用自定义例程（可能是 SSIS 包）或使用 SQL 复制来复制这些源表。根据您的业务需求，这可能很复杂（例如，源系统中的更改需要多快反映在报告中？）
• 如果源表太大（并且您需要所有行），这可能不可行

我实际上同意 spaghettidba 的观点，即为不同的报告构建单独的查询/视图具有许多优点（或者至少有多个视图，如果您有一些非常相似的报告可以使用相同的来源） - 我的建议与此不冲突，您可以复制源表并构建单独的查询/视图。