Question

我有一个数据表，每周更新一次。然后，我有一个查询来处理这些数据，并基本上返回一个代码列表和预订这些代码的小时数。此查询相当复杂，大约需要5秒钟才能运行。

这些数据需要被DB中的许多其他查询使用，所以我想把它放在某个地方，以便其他查询可以轻松访问它。在视图中执行此操作似乎是一个好主意，但这意味着每次调用此视图时，它将重新运行此查询，需要5秒钟，如果在一次调用中有很多调用，那么它将导致应用程序放慢速度。

所以我在想，如果在星期一导入数据时将这个视图创建为表会更好，因为这将是唯一一次更改。这是最好的想法，还是我看错了？

Answer 1

一位同事向我指出了“物化观点”。

基本上，您将数据从视图复制到表中，并将此表用作视图。该演示文稿（链接）中的要点是您可以使用触发器和函数来仅更新该表的某些部分。

非常有用，我在SQL Server中实现了这样一个物化视图。

Answer 2

听起来像是一种合理的方式。

由于查询费用昂贵，将结果放在“报告”表中供其他应用程序使用听起来像是一个很好的妥协。

只要这些数据的用户对您所描述的更改感到满意，您的方法就可以了。

Answer 3

我处理大多数项目的相同问题。

我们有大量数据需要针对不同目的进行重组。我们还受益于用于批量作业和隔夜流程的企业文化，因此用户可以很好地了解数据的快照特性。大多数用户首先将数据导出到Excel，因此这不是问题。

使用附加表是一种明智的方式。

就个人而言，我在这些表格前加下划线。

_LargeUsefulData

这使我能够轻松识别在系统正常操作中起主动作用的实体的便利表。

Answer 4

如果您的视图结构允许对其进行索引，则可以创建索引视图（实际上只是在更新基础表时更新的数据副本）。

但并非每个查询都允许对其进行索引编制。

如果您的数据不是实际的二分之一，则创建表格为OK。

Answer 5

您仍在“查看”您的行，无论是在表格中还是在表格行的视图中。

我首先尝试优化您的查询（点击索引，可能添加/更新/更改索引）并通过分析器运行它。 Profilers为您的数据库的决策计划提供了很好的洞察力。

Answer 6

是的，它是向数据仓库方向迈出的第一步:) 当然，您应确保在每周更新后始终构建新表。

Answer 7

我在生产支持中遇到过类似的问题，我需要处理大型数据仓库。基本上，我所做的是，我使用shell脚本创建了表。 shell脚本以这种方式运行：

所有这一切都可以使用简单的shell脚本完成。我发现它非常有用，即使现在它也在有效运行。