Report based on selection criteria in an Apex collection

Question

For my current page I have to deal with a horrible "EAV" (Entity-Attribute-Value) table design like this:
Employee ---< Attribute Value >-- Attribute
So you might query who works in dept 10 and earns 20000 and was hired om 01-Jan-2007 like this:
select emp.ename
from emp
join attribute_value a1 on a1.empno = emp.empno and a1.att_name = 'DEPT'
join attribute_value a2 on a2.empno = emp.empno and a2.att_name = 'SALARY'
join attribute_value a3 on a3.empno = emp.empno and a3.att_name = 'HIREDATE'
where a1.att_numeric_value = 10
and   a2.att_numeric_value = 20000
and   a3.att_date_value = date '2007-01-01';(I said it was horrible!)
But to make matters worse, the form for entering query criteria is also based on the attributes table as a tabular form:
select apex_item.display_and_save(1,att_name) att_name
,      apex_item.text(2,null) att_value
from   attributes
where  att_type = 'EMPLOYEE';The user may enter values for any number of attributes and run the query. So in my example, there maybe be 0, 1, 2 or 3 criteria to use (or more when new attributes are added to the table).
I can code the report query as a "PL/SQL body returning SQL query" and build a SQL string exactly like my example above - all literal values. Is there any way I could do it that uses bind variables? Given the variable number of bind variables I think I'd need to use DBMS_SQL, but would I be able to integrate that into an Apex report region source? Or is there another way?
I'm open to any suggestions! (Except "redesign the database": much as I'd like to, I can't.)

Answer 1

If you are sure of the number of attributes the user will be using as criteria is fixed and will not change, you should able to bind the literals to page items like:
select emp.ename
from emp
join attribute_value a1 on a1.empno = emp.empno and a1.att_name = 'DEPT'
join attribute_value a2 on a2.empno = emp.empno and a2.att_name = 'SALARY'
join attribute_value a3 on a3.empno = emp.empno and a3.att_name = 'HIREDATE'
where a1.att_numeric_value = :P1_dept_value
and   a2.att_numeric_value = :P1_salary_value
and   a3.att_date_value = to_date(:P1_hiredate_value,'YYYY-MM-DD');or
select emp.ename
from emp
join attribute_value a1 on a1.empno = emp.empno and a1.att_name = :P1_att1_name
join attribute_value a2 on a2.empno = emp.empno and a2.att_name = :P1_att2_name
join attribute_value a3 on a3.empno = emp.empno and a3.att_name = :P1_att3_name
where a1.att_numeric_value = :P1_att1_value
and   a2.att_numeric_value = :P1_att2_value
and   a3.att_date_value = to_date(:P1_att3_value,'DD-MM-DD');What happens when your user wants to add another attribute and use it as search criteria. You have to:
1) add a JOIN clause to the SELECT
2) add to the WHERE clause to the SELECT
Warning personal opinion to follow: I would give up binding (i.e.. skipping parsing os the SELECT statement) for the flexibility of generating the SELECT at runtime. If the user adds a new attribute, then the PL/SQL code that assembles the SELECT statement would not have to be changed. All the meta data is stored in the database as to what the new column is and which column in the attributes table to use (ATT_NUMERIC_VALUE or ATT_DATE_VALUE). If your method of displaying the attributes and receiving the user's criteria is dynamic like my example, then you would not have to change the application at all for new attributes.
Just my 2 cents worth of opinion,
Mike