PL/SQL Ad-hoc Reporting Implementation Questions

Question

Recently, I have been put on a development team that is developing a small reporting module for one of our applications.
I'm trying to mask the underlying structure from the application by having the application run PL/SQL procedures which return REF CURSORS to the client with the requested data. Right now I'm struggling with how to implement the PL/SQL in the best fashion.
Since this is a reporting tool the user has many combinations of selections. For example at a high level this application has a combination of multiple dropdowns (4-6), radio buttons, and check boxes. As you can see this results in a high amount of possible combinations that have to be sent to the database.
Basically, the user chooses the following:
1. Columns to receive (ie different SELECT lists in the PL/SQL)
2. Specific conditions (ie different WHERE clauses in the PL/SQL)
3. Aggregate functions (SUMS, TOTALS, AVERAGES based on #1 and #2)
4. Trends based on #3.
So... with that said I see two possibilities:
1. Create a static query for each combination of parameters (in this case that would most likely result in at least 300 queries that would have to be written, possibly 600+).
The problem I see with this is that I will have to write a significant amount of queries. This is a lot of front end work that, while is tedious, could result in a better performing system because it would be a parse once, execute many scenario which is scalable.
The downside though is that if any of the underlying structure changes I have to go through and change tens of queries.
2. Use DBMS_SQL and dynamically generate the queries based on input conditions.
This approach (possibly) sacrifices performance (parse once, execute once situation), but has increased maintainability because it is more likely that I'll have to make one change vice a number of changes in scenario 1.
A downside to this is that, it may be harder to debug (and hence maintain) because the SQL is generated on the fly.
My questions to all is:
1. Which is the approach that would best manage maintainability / performance?
2. Is there any other approaches to using PL/SQL as a reporting tool that I am not thinking of?
The database is 10.2.0.3, and the 'application' is PHP 5.1 running on IIS 6.
If you need me to provide any additional information please let me know.
Thanks!

Answer 1

Ref cursors are an ugly solution (different though in 11g).
You build a dynamic SQL. It must/should have bind variables. But a ref cursor does not allow you to dynamically bind values to bind variables. You need to code the actual bind variables into the code as part of the open cursor command. And at coding time you have no idea how many bind variables there will be in that dynamic SQL for the ref cursor.
The proper solution is DBMS_SQL as it allows exactly this. Also one of the reasons why APEX uses this for its report queries.
The only sensible way to implement this type of thing in PL/SQL is by not trying to make it generic (as one could with DBMS_SQL). Instead use polymorphisms and have each procedure construct the appropriate ref cursor with bind variables.
E.g.
SQL> create or replace package query as
2 procedure Emp( c in out sys_refcursor );
3 procedure Emp( c in out sys_refcursor, nameLike varchar2 );
4 procedure EMp( c in out sys_refcursor, deptID number );
5 end;
6 /
Package created.
SQL>
SQL> create or replace package body query as
2
3 procedure Emp( c in out sys_refcursor ) is
4 begin
5 open c for select * from emp order by 1;
6 end;
7
8 procedure Emp( c in out sys_refcursor, nameLike varchar2 ) is
9 begin
10 open c for select * from emp where ename like nameLike order by 1;
11 end;
12
13 procedure EMp( c in out sys_refcursor, deptID number ) is
14 begin
15 open c for select * from emp where deptno = deptID order by sal;
16 end;
17 end;
18 /
Package body created.
SQL>
SQL> var c refcursor
SQL> exec query.Emp( :c, 'S%' )
PL/SQL procedure successfully completed.
SQL>
SQL> print c
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
7369 SMITH CLERK 7902 1980-12-17 00:00:00 800 20
7788 SCOTT ANALYST 7566 1987-04-19 00:00:00 3000 20
SQL>