通过拆分为多个游标来重构大型游标查询
又一个 PL/SQL 重构问题!
我有几个一般简化形式的游标:
cursor_1 is
with X as (select col1, col2 from TAB where col1 = '1'),
Y as (select col1, col2 from TAB where col2 = '3'),
/*main select*/
select count(X.col1), ...
from X inner join Y on...
group by rollup (X.col1, ...
cursor_2 is
with X as (select col1, col2 from TAB where col1 = '7' and col2 = '9' and col3 = 'TEST'),
Y as (select col1, col2 from TAB where col3 = '6'),
/*main select*/
select count(X.col1), ...
from X inner join Y on...
group by rollup (X.col1, ...
cursor_2 is
with X as (select col1, col2 from TAB where col1 IS NULL ),
Y as (select col1, col2 from TAB where col2 IS NOT NULL ),
/*main select*/
select count(X.col1), ...
from X inner join Y on...
group by rollup (X.col1, ...
...
begin
for r in cursor_1 loop
print_report_results(r);
end loop;
for r in cursor_2 loop
print_report_results(r);
end loop;
...
end;
基本上,所有这些游标(超过 3 个)都是相同的摘要/报告查询。区别在于因子子查询。始终有 2 个因子子查询“X”和“Y”,并且它们始终选择相同的列来馈送到主报告查询中。
问题是主要报告查询非常大,大约 70 行。这本身并没有那么糟糕,但它是为所有报告查询复制粘贴的(我认为有十多个)。
由于唯一的区别在于分解的子查询(它们都返回相同的列,这实际上只是它们选择的表及其条件的区别),我希望找到一种方法来重构所有这些,以便有一个查询对于大型报告和各种因子子查询的较小报告,这样当对报告的完成方式进行更改时,我只需在一个地方进行,而不是十几个。更不用说更容易浏览(和读取)文件了!
我只是不知道如何正确重构这样的东西。我在想管道功能?我不确定它们是否适合这个,或者是否有更简单的方法......
另一方面,我也想知道通过拆分报告查询性能是否会明显变差。性能(速度)是该系统的一个问题。如果它会显着增加执行时间,我宁愿不为了开发人员的方便而引入更改。
我想我最终想要的是看起来像这样的东西(我只是不确定如何做到这一点以便它能够实际编译):(
cursor main_report_cursor (in_X, in_Y) is
with X as (select * from in_X),
Y as (select * from in_Y)
/*main select*/
select count(X.col1), ...
from X inner join Y on...
group by rollup (X.col1, ...
cursor x_1 is
select col1, col2 from TAB where col1 = '1';
cursor y_1 is
select col1, col2 from TAB where col2 = '3'
...
begin
for r in main_report_cursor(x_1,y_1) loop
print_report_results(r);
end loop;
for r in main_report_cursor(x_2,y_2) loop
print_report_results(r);
end loop;
...
使用 Oracle 10g)
Another PL/SQL refactoring question!
I have several cursors that are of the general simplified form:
cursor_1 is
with X as (select col1, col2 from TAB where col1 = '1'),
Y as (select col1, col2 from TAB where col2 = '3'),
/*main select*/
select count(X.col1), ...
from X inner join Y on...
group by rollup (X.col1, ...
cursor_2 is
with X as (select col1, col2 from TAB where col1 = '7' and col2 = '9' and col3 = 'TEST'),
Y as (select col1, col2 from TAB where col3 = '6'),
/*main select*/
select count(X.col1), ...
from X inner join Y on...
group by rollup (X.col1, ...
cursor_2 is
with X as (select col1, col2 from TAB where col1 IS NULL ),
Y as (select col1, col2 from TAB where col2 IS NOT NULL ),
/*main select*/
select count(X.col1), ...
from X inner join Y on...
group by rollup (X.col1, ...
...
begin
for r in cursor_1 loop
print_report_results(r);
end loop;
for r in cursor_2 loop
print_report_results(r);
end loop;
...
end;
Basically, all of these cursors (there's more than 3) are the same summary/reporting queries. The difference is in the factored subqueries. There are always 2 factored subqueries, "X" and "Y", and they always select the same columns to feed into the main reporting query.
The problem is that the main reporting query is VERY large, about 70 lines. This itself isn't so bad, but it was copy-pasted for ALL of the reporting queries (I think there's over a dozen).
Since the only difference is in the factored subqueries (and they all return the same columns, it's really just a difference in the tables they select from and their conditions) I was hoping to find a way to refactor all this so that there is ONE query for the giant report and smaller ones for the various factored subqueries so that when changes are made to the way the report is done, I only have to do it in one place, not a dozen. Not to mention a much easier-to-navigate (and read) file!
I just don't know how to properly refactor something like this. I was thinking pipelined functions? I'm not sure they're appropriate for this though, or if there's a simpler way...
On the other hand, I also wonder if performance would be significantly worse by splitting out the reporting query. Performance (speed) is an issue for this system. I'd rather not introduce changes for developer convenience if it adds significant execution time.
I guess what I'd ultimately like is something that looks sort of like this (I'm just not sure how to do this so that it will actually compile):
cursor main_report_cursor (in_X, in_Y) is
with X as (select * from in_X),
Y as (select * from in_Y)
/*main select*/
select count(X.col1), ...
from X inner join Y on...
group by rollup (X.col1, ...
cursor x_1 is
select col1, col2 from TAB where col1 = '1';
cursor y_1 is
select col1, col2 from TAB where col2 = '3'
...
begin
for r in main_report_cursor(x_1,y_1) loop
print_report_results(r);
end loop;
for r in main_report_cursor(x_2,y_2) loop
print_report_results(r);
end loop;
...
(Using Oracle 10g)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
为主查询创建视图怎么样?这可以美化您的代码并集中启动主要查询。
What about creating a view for the main query? That pretties up your code and centralizes the main query to boot.
使用管道函数。例如:
创建函数流水线
MAIN 过程示例
所有各种子查询都简化为对单个流水线函数的调用,该函数确定要返回的行。
编辑:
要将所有需要的类型和函数合并到 1 个过程中,并使用变量作为子查询函数参数,我添加以下示例:
请注意,现在的好处是,即使您有许多不同的游标,您也只需定义主查询和子查询SQL各一次。之后,您只需更改变量即可。
干杯
Use a pipelined function. For example:
Create the function pipelined
MAIN procedure example
All of your various subqueries are reduced to a call to a single pipelined function, which determines the rows to return.
EDIT:
To combine all needed types and functions into 1 procedure, and also to use variables for subquery function parameters, I'm adding the following example:
Note the benefit now is that even if you have many different cursors, you only need to define the main query and subquery SQL once. After that, you're just changing variables.
Cheers
这个解决方案比管道方法有点奇怪,并且需要 3 个新的视图对象,但它可能会运行得更快
因为 SQL 和 PL/SQL 之间的上下文切换较少。
This solution is a little weirder than the pipelined approach, and requires 3 new objects for the views, but it will probably run faster
since there is less context switching between SQL and PL/SQL.
您可以考虑的一种可能性是为 X 和 Y 使用 2 个全局临时表 (GTT)。那么您只需要一个游标,但您必须多次清除并重新填充 2 个 GTT - 如果数据量很大,您可能需要每次也可以获得 GTT 的优化器统计数据。
这就是我的意思:
因此,相同的 2 个 GTT 会被重新填充,并且每次都会使用相同的游标。
One possibility you could consider is using 2 Global Temporary Tables (GTTs) for X and Y. Then you just need one cursor, but you have to clear and re-populate the 2 GTTs several times - and if data volumes are large you may want to get optimiser stats on the GTTs each time too.
This is the sort of thing I mean:
So the same 2 GTTs are re-populated and the same cursor is used each time.