What are some good practices of modular code? - plsql

Question

In PL-SQL, there are some fancy new concepts, like table functions, objects, and probably others I have not discovered yet.
But then again, there is also plain simple code generation (dynamic pl-sql) that you can "execute immediately".
These can help with code reuse.
From what I can tell, table functions and objects can help with creating modular code, but still not enough to remove the entire of it (maybe I am not using the best of them; I have to admit my objects only contain data for now and no logic).
On the other side, the code generating is much more simple, and can reduce duplicate code more. But it is kind of hard to read what the actual business is behind the code generation logic.
I want modular and not-duplicate code. Should I stick with plain code generation? What are some pros and cons of each?

Answer 1

Dynamic SQL is generally better than advanced PL/SQL features like table functions, object-relational types, data cartridge, the ANY* types, etc. With a few simple tips you can avoid the pitfalls of dynamic SQL and use it to create modular systems.
Advanced PL/SQL features are cool, and at some point you'll have to use them at least a little. They're great for solving weird, specific problems. But you will almost certainly regret creating an Oracle system that is centered around one of those features. I've wasted weeks or months of my life on each of the above PL/SQL features.
Dynamic SQL
Pro - It always works. It might be painful, but there's always a way to make it work in SQL and make it run fast.
Con - A little harder to read and write.
Advanced PL/SQL
Pro - Cool features, elegant code that can perfectly solve certain problems.
Con - Will let you down at a critical moment.
It's hard to give examples of advanced PL/SQL failures without writing a novel. The stories typically go something like this: "We combined features A, B, C ... we hit bugs X, Y, Z ... everyone got angry ... we spent a month re-writing it."
Dynamic SQL doesn't have to be so bad. It just takes some discipline.
Good formatting and instrumenting. Make sure the dynamic SQL looks beautiful and it can be easily printed out for debugging. Follow good programming practices - indent, add comments, use meaningful names, etc. It will be a shock to the point-and-click programmers when the "Beautifier" button on the IDE doesn't help them. Don't let anyone get away with sloppy code - just because it's technically a string shouldn't allow anybody to avoid common style rules.
Alternative quoting mechanism. Use the q syntax to avoid constantly escaping things. For example, q'[I'll use single quotes if I want to!]' instead of 'I''ll use single quotes if I want to!'.
Templates instead of concatenation. Write the code in un-interrupted blocks and then replace the dynamic parts later. Combine it with the q strings to avoid a million quotation marks and pipes in the code. For example:
v_dynamic_sql_template constant varchar2(32767) :=
q'[
select a, b, $DYNAMIC_SELECT_LIST$
from table1
$DYNAMIC_JOIN_1$
where table1.a > 1
$DYNAMIC_WHERE_1$
]';
...
v_dyanmic_sql := replace(v_dynamic_sql_template, '$DYNAMIC_SELECT_LIST$', v_variable);
...
(In this question I assume you are an intermediate or advanced Oracle developer. If you're a beginner, the answer is probably static SQL statements but you haven't
seen enough SQL features to realize that yet.)