在 SQL Server 中查看与表 [关闭]

Question

任务：出于仪表板的目的，我有一个复杂的选择查询，其中包含许多从多个表中获取数据的连接和子查询。

选项 1：我可以使用该 SELECT 查询创建一个视图，而 Spotfire 可以将该视图用作其仪表板的数据源。

选项 2：我可以使用 SELECT 查询作为源来创建 SSIS 包，并且可以将数据加载到单个表中每天一次。 Spotfire 可以使用该单个表作为其仪表板的来源。

注意：我不希望它是实时的。仪表板可以每晚更新一次（每天一次）。

我的理解：我知道视图基本上是一个存储的SELECT 查询。如果我创建一个视图，每次用户访问仪表板时，它都会尝试访问该视图。这意味着，在后端视图将命中数据库中的基础表。取而代之的是，我可以简单地让 SSIS 每天加载一次特定的表。这样 Dash 将触及这个表，而不是实际的高度事务性表。

你能建议我一个选项和解释吗？

Answer 1

在某种程度上，这是一个见仁见智的问题。但是，您已经定义了以下情况：

• 仪表板每天仅更新一次，因此在白天应该保持不变。
• 基础表用于事务目的。
• 必需的查询至少有些复杂。

结合起来，这些强烈主张在半夜创建仪表板表，以简化查询。

在许多环境中，底层事务表不直接用于报告。而是将表格复制到报告环境（定期或实时），然后报告环境用于报告。

Answer 2

您似乎已经涵盖了大部分问题。

View 的优势在于它是实时的，在报告运行的那一刻。缺点是它是系统上的实时负载，不仅包括 CPU、RAM 和磁盘 I/O，还包括（通常更重要的）表和行锁。

SSIS 包的优势在于将您的报告负载与生产负载断开连接（再次重申：尤其是减少锁定争用在这里是一个胜利），并且能够创建特殊的仅报告索引以使您的报告运行得更快而不必需要在实时表发生更改时维护这些索引（特别是因为用于报告的索引通常与用于生产更新的索引非常不同）。缺点是增加了复杂性和故障点（如果 SSIS 包开始失败怎么办？）、过时的数据，以及如果您只是移动到同一服务器上的特殊表，报告仍然使用一些 CPU、磁盘和来自生产服务器的 RAM 资源，即使它减少了。

就我个人而言，我更喜欢使用视图，直到我不使用 :) 为止。

我的意思是，一旦我开始使用 SSIS 包将数据移动到单独的报告位置，我就想“全力以赴”进行该过程。不要只在同一台服务器上做一份报告或表格；获得一个单独的报告服务器（甚至是一个成熟的数据仓库解决方案）并尽可能多地转移到它上面。然后确保有人负责监控它的运行状况和迁移包的运行状况。我还将开始努力改变企业文化，让每个人都能轻松地看到昨天的数据。但我想尽可能地推迟它，并坚持使用 Views，直到我开始看到一个切实的理由转向某种真正的数据仓库或分析产品来证明这笔费用是合理的。

Answer 3

首先，我同意 cmets 和围绕它的答案取决于您的要求。以我的经验，VIEW 选项最初总是很吸引人，因为它易于实施和维护，因为移动部件较少。

但是，随着数据量的增加，仪表板的性能以及对底层事务系统的负面性能影响最终导致重构实施。

在我们的场景中，将报告的关注点与事务系统分开是正确的做法。为我们的报告实施物化视图（想想数据快照），消除了困扰用户并给系统带来坏名声的锁定、超时和服务器过载。

如果您有足够的时间并相信您的数据量可能会显着增长，请认真考虑具体化视图。