Stored procedure to identify column names from a lookup table

Question

I have a working PL/SQL stored proc as below:
CREATE OR REPLACE PROCEDURE PROC_TEST IS
CURSOR GET_TEST_VALUES IS
SELECT
MF_master.comp_service_b,MF_master.normal_form_amount_b, MF_master.plan_id_b, MF_master.plan_percentage_b, MF_master.plan_service_b,MF_master.autoid,     ORA_master.comp_service_v, ORA_master.normal_form_amount_v,
ORA_master.plan_id_v, ORA_master.plan_percentage_v,
ORA_master.plan_service_v, ORA_master.autoid,     ORA_master.test_var     FROM MF_master, ORA_master
WHERE ((MF_master.autoid = ORA_master.autoid));
BEGIN
FOR REC IN GET_TEST_VALUES LOOP
begin
if rec.test_var='SVC' then
if (to_number(rec.plan_service_b) = to_number(rec.plan_service_v) ) and
(to_number(rec.comp_service_b) = to_number(rec.comp_service_v) ) then
update ORA_master set status_v = 'COMPLETE',last_updt_user_v = 'PROCEDURE',last_updt_date_v = SYSTIMESTAMP where autoid = rec.autoid;
else
update ORA_master set status_v = 'INCOMPLETE',last_updt_user_v = 'PROCEDURE',last_updt_date_v = SYSTIMESTAMP where autoid = rec.autoid;
end if;
end if;
if rec.test_var = 'TERM' then
if (to_number(rec.plan_percentage_b) = to_number(rec.plan_percentage_v) ) and
(to_number(rec.normal_form_amount_b) = to_number(rec.normal_form_amount_v) )
then
update ORA_master set status_v = 'COMPLETE',last_updt_user_v = 'PROCEDURE',last_updt_date_v = SYSTIMESTAMP where autoid = rec.autoid;
else
update ORA_master set status_v = 'INCOMPLETE',last_updt_user_v = 'PROCEDURE',last_updt_date_v = SYSTIMESTAMP where autoid = rec.autoid;
end if;
end if;
     end;
     END LOOP;
     COMMIT;
END;
What I am doing here is, if test_var = 'SVC', I am comparing 2 columns, plan_service_b and comp_service_b(with plan_service_v and
comp_service_v)
Similarly, for test_var = 'TERM', it is plan_percentage_b and normal_form_amount_b(with plan_percentage_v and normal_form_amount_v)
The above works fine as of now, but I am looking for a way to make this design more dynamic. In other words, these comparison columns may change from time
to time and each time something changes, I will have to change this code. Rather, I am looking for a way to have the comparison columns in a
lookup table that I can query to get what needs to be compared.
My thought is :
CREATE TABLE COMPARISON_COL_LOOKUP
(test_var VARCHAR2(10),
MF_column VARCHAR2(30),
ORA_column VARCHAR2(30) );
And then, insert
INSERT INTO COMPARISON_COL_LOOKUP ('SVC','PLAN_SERVICE_B','PLAN_SERVICE_V');
INSERT INTO COMPARISON_COL_LOOKUP ('SVC','COMP_SERVICE_B','COMP_SERVICE_V');
INSERT INTO COMPARISON_COL_LOOKUP ('TERM','PLAN_PERCENTAGE_B','PLAN_PERCENTAGE_V');
INSERT INTO COMPARISON_COL_LOOKUP ('TERM','NORMAL_FORM_AMOUNT_B','NORMAL_FORM_AMOUNT_V');
commit;
In this way, when tomorrow, when something changes - like new columns need to be compared for SVC or TERM, OR, if any comparisons need to
be removed, all I need to do is to change the data in this lookup table !
Now here's my question --- If I have this lookup table, how best can I update my above stored procedure to use this lookup table so that I don't need to
hard-code the column names for comparison ?
Any thoughts/suggestions are appreciated.

Answer 1

While it is certainly technically possible to use dynamic SQL here, I would suggest that you make absolutely certain that you're not making things unnecessarily complicated...
Dynamic SQL is generally substantially harder to write, debug, and maintain than equivalent static SQL. In addition, it takes a lot more work to ensure that dynamic SQL performs as well as static SQL (i.e. you now have to explicitly use bind variables) and that you're not introducing security holes via SQL injection.
If your comparisons are likely to change infrequently, and particularly as those changes would imply changes to the underlying requirements, I would tend to be biased toward keeping the working procedure and just planning on making code changes periodically.
Of course, not knowing your particular requirements, I certainly can't be certain that dynamic SQL would be inappropriate here, but I have seen lots of folks unnecessarily complicate their systems by building overly flexible systems that were painful to support and extend.
Justin