Is there table type object in PL/SQL?

Question

Hi.
What I'm trying to do is, according to the some conditions, aggregate data as an object type( I am not sure that there's a similar thing)
There are 5-6 conditions. then at last join those table type object.
FYI, Here is an example
Company will give bonus to a person who meet these conditions
1. Salary is less than 1000$ - salary table
2. More than 5 persons in his family - staff table
3. gross sale is over 10000$
In PL/SQL Package, I'll get those data as an object type and join those object just like in-line query.
select emp_no
from sal_tbl , staff_tbl, sale_tbl
where sal_tbl = staff_tbl
and sal_tbl = sale_tbl
In my opinion I can get employee list who get bonus. because they meet all conditions.
Reason why bonus condition will be updated continuously. I want to make them easy to maintanence. what if I need to add new conditions. Just add a new procedure that calculate new result and pass as an table type object.
select emp_no
from sal_tbl , staff_tbl, sale_tbl, new_tbl*
where sal_tbl = staff_tbl
and sal_tbl = sale_tbl
and sal_tbl = new_tbl*
Is there any thing just like what I think?
Thanks in advance
Message was edited by: me
allbory
I have read Oracle user guide - Collection, Record, and Cursor. But I can't get anything that I want.
Give me some clues

Answer 1

> In PL/SQL Package, I'll get those data as an object type and join those object just like
in-line query.
Not the best of ideas. If I'm getting what you're saying, you want to use the following approach:
SQL> create or replace type TStrings as table of varchar2(4000);
2 /
Type created.
SQL>
SQL>
SQL> create or replace procedure BadIdea( collection TStrings ) is
2 minVal string(4000);
3 maxVal string(4000);
4 begin
5 -- in the procedure we now run SQLs against the collection
6 select
7 MIN( column_value ) into minVal
8 from TABLE( collection );
9
10 select
11 MAX( column_value ) into maxVal
12 from TABLE( collection );
13 end;
14 /
Procedure created.
SQL> show errors
No errors.
SQL>
SQL>
SQL> -- and then we call this procedure to do our "SQL" processing for us
SQL> declare
2 list TStrings;
3 begin
4 select
5 object_name bulk collect into list
6 from user_objects;
7
8 BadIdea( list );
9 end;
10 /
PL/SQL procedure successfully completed.A collection of objects resides in (non-sharable and expensive) PL/SQL memory. Running SQL, requires the PL/SQL engine copying the data to the SQL engine into a structure and format that the SQL engine will understand.
This is slow. This is expensive. This does not scale.
It makes little sense to copy data from the very fast and hot and good and scalable db buffer cache into an expensive memory structure in the PGA and then run SQLs against that.
> Reason why bonus condition will be updated continuously. I want to make them easy
to maintanence. what if I need to add new conditions. Just add a new procedure that
calculate new result and pass as an table type object.
The way I read your SQL, your new_tbl* requires dynamic SQL. Which means you also need to dynamically cater for the correct column names to join on, to filter on, and to select from.
Also not the best of ideas. Dynamic SQL like that requires a lot of code to deal correctly with bind variables. Lot of exception handling as there can easily be run-time errors as the code itself that is executed in turn creates new dynamic code to execute.
If this is to be truly dynamic, then one approach would be that each rule needs to be executable as a SQL or PL/SQL block. Each rule needs to have an input like an employee number. Each rule needs to returns a boolean like value, saying whether the rule has passed or failed.
Only when all the rules have been passed, can the bonus be allocated.
This will deal fine with the "dynamic rule" requirement. Performance wise and scalability wise.. it may not be the best of ideas. 10 dynamic and very slow and expensive rules, could very well be rewritten as a one very fast and very cheap static SQL statement.
Anyway, the dynamic rule approach can look something like the following:
SQL> create or replace type TBonusRule is object
2 (
3 result# char(1),
4 member function Passed return boolean
5 )
6 not final;
7 /
Type created.
SQL> show errors
No errors.
SQL>
SQL>
SQL> create or replace type body TBonusRule is
2 member function Passed return boolean is
3 begin
4 return( UPPER(self.result#) = 'Y' );
5 end;
6 end;
7 /
Type body created.
SQL> show errors
No errors.
SQL>
SQL>
SQL> create or replace type TBonusSQLRule under TBonusRule
2 (
3 constructor function TBonusSQLRule( empNo number, sqlStatement varchar2 ) return self as result
4 ) final;
5 /
Type created.
SQL> show errors
No errors.
SQL>
SQL>
SQL> create or replace type body TBonusSQLRule is
2 constructor function TBonusSQLRule( empNo number, sqlStatement varchar2 ) return self as result is
3 begin
4 execute immediate sqlStatement
5 into self.result#
6 using IN empNo;
7
8 return;
9 end;
10
11 end;
12 /
Type body created.
SQL> show errors
No errors.
SQL>
SQL> set serveroutput on
SQL> declare
2 rule1 TBonusSQLRule;
3 rule2 TBonusSQLRule;
4 empNo number;
5 begin
6 empNo := 7369; -- we process employee 7369
7
8 -- we apply bonus rule 1 that check if the employee is a clerk (of course,
9 -- we could be reading these rules from a rules table - this example simply
10 -- creates them dynamically)
11 rule1 := new TBonusSQLRule( empNo, 'select ''Y'' from emp where empno = :0 and job=''CLERK''' );
12
13 if rule1.Passed then
14 DBMS_OUTPUT.put_line( 'Rule 1. PASSED' );
15 else
16 DBMS_OUTPUT.put_line( 'Rule 1. FAILED' );
17 end if;
18
19 -- rule 2 can for example check if the employee has been working for at least 5 years for the
20 -- company
21 rule2 := new TBonusSQLRule( empNo, 'select ''Y'' from emp where empno = :0 and (SYSDATE-hiredate)>5*365' );
22
23 if rule2.Passed then
24 DBMS_OUTPUT.put_line( 'Rule 2. PASSED' );
25 else
26 DBMS_OUTPUT.put_line( 'Rule 2. FAILED' );
27 end if;
28
29 end;
30 /
Rule 1. PASSED
Rule 2. PASSED
PL/SQL procedure successfully completed.
SQL>
PL/SQL rules can in a similar fashion be subclassed from the base/asbtract class. And rules can be persisted in a table too.
But even though I did this example to illustrate just how flexible Oracle can be, I would personally think hard before using the above approach myself.
Why?
Because rules 1 and 2 resulted in two SQLs being fired. A single SQL could have done the job.
2 SQLs were used for a single employee. I can use a single SQL to find ALL employees that matches the rule criteria.
So... not very scalable and not very fast.