管理非常大的SQL查询

时间:2014-08-07 15:21:03

标签: sql oracle data-warehouse

我正在寻找在Oracle中管理非常大的SQL查询的一些想法。

我的雇主希望为每份报告构建非常广泛的报告(150 - 200)列数据。 每个项目都是子查询或视图中的元素。数据必须是实时的,因此DW样式批处理不是一种选择。我们也不使用任何BI工具,只是一个生成Excel的Java应用程序(它是在Excel中输出数据的要求)

该查询还包含联合作为来自其他系统的订阅源。 查询导致非常大的SQL(大约1500行)非常难以管理。

我可以采用哪些策略来使工​​作更易于管理?

这也不是性能问题。我能够优化查询效率非常高,其查询的大部分宽度,管理200列本身就是一个挑战。

2 个答案:

答案 0 :(得分:4)

我每天处理这么长的查询,这里有一些帮助我修改它们的内容:

首先为这些列中的每一列添加别名。在构建它时,您可能知道每个来自哪里但是何时需要进行更改,确切地知道每列的来源确实很有帮助。这适用于连接条件,分组依据和条件以及选择列。

组织易于理解和可测试的块。我使用临时表来提取有意义的东西,因此我可以在测试模式下查看最终查询之前的结果。

这让我进入测试模式。如果我有数据块,我用测试模式设计proc,然后在测试模式下查询各个临时表,这样我就可以看到如果有错误,数据出错的地方。不确定Oracle是如何工作的,但是在SQL Server中,我将它作为最后一个参数并给它一个默认值,这样它就不需要由应用程序传入。

考虑记录执行细节和传入参数的值,并确保记录任何错误消息。当您必须解决为什么这个已经完美运行六年的报告对这个用户不起作用时,这将有很大帮助。

将列放在每个单独的行上,并对where子句执行相同的操作。有时您可能不得不通过注释掉连接来解决问题,直到找到导致问题的连接。如果您也可以轻松注释掉相关字段,那就更容易了。

如果您没有技术设计文档,那么至少要使用注释来解释您的思考过程。你想在任何评论中理解为什么不是如何。这些东西很难再回来,甚至在你写的时候也能理解。给你未来的自己一些帮助。

在从头开始开发时,我将选择列表放入,然后注释除第一项之外的所有项目。然后我只构建查询,直到我得到该值 - 测试,直到我确定我得到的是正确的。然后我添加下一个和任何连接或我可能需要获得它的条件。再次测试确保它是正确的。 (哎呀为什么在我添加的时候从1000条记录到20000条呢?嗯,也许我需要处理那些东西或者那是对的?)通过一次只添加一个东西,你会发现逻辑错误很多更快,对结果更有信心。与尝试一次性构建大量查询相比,它也会花费更少的时间。

最后,理解您的数据是无可替代的。有很多复杂的查询可以正常工作,但没有给出正确的答案。知道您是否需要内部联接或左联接。了解获取所需记录所需的条件。知道当你有一对多的关系时如何处理记录(这可能需要推迟要求);你应该有3行(每个子记录一个),或者你应该将这些数据放在逗号分隔列表中,或者你应该只选择其中一个记录并使用聚合一行。如果是后者,选择想要保留的记录的标准是什么?

答案 1 :(得分:2)

如果没有看到问题的具体细节,可以立即想到以下几点:

  • 如果您纯粹是为了管理,我建议您将子查询组织为views,然后在最终查询中引用这些视图。

  • 另一方面,为了提高性能,您可能需要考虑创建临时表甚至materialized views(这些是固定视图)以分解流程中较重的部分。

  • 如果您的查询需要大量子查询才能获得可用数据,您可能需要重新考虑数据库设计,并可能创建一些datamarts来轻松访问报告数据。可以把这些看作是迷你仓库没有多年的趋势数据。

  • 最后,我知道你说过你不使用任何商务智能工具,但这个问题看起来似乎是将数据整理到多维数据集"或业务对象" Universes"。至少可以节省引入BI工具的成本与编程时间以支持当前设置。