Re: PL/SQL Execute Immediate

On Sat, 19 Apr 2003, damorgan_at_exesolutions.com wrote:

> This has the feeling, at least to me, of trying to view every
> problem as a nail and thus applying a hammer.

But, to use your analogy against you, you apply a hammer to pretty much every newsgroup answer you give. You apply the production DBA hammer.

When one develops, he may run across:

• The same exact SQL to tie a primary key generated from a sequence directly to a table by sticking it in a trigger and soon, and he'll start a mini project to build code that builds those things.
• Have a history strategy which has the same exact key as the table its keeping history on with maybe a transaction sequence added to it, and soon he'll start a mini project to build code that builds those things.
• Maybe he has a trigger which writes to some particular asyncronous batching process, and this happens on alot of entities. That sounds like a mini project to build code that builds those things.

There's three and that would be enough for me to not use your style of answering every post about dynamically built database objects with a production dba hammer which tries to slam the idea. (with a rather tiresome Daniel Morgan flavor of condescension to boot)

> I am of the belief that every trigger should be carefully considered
> both for its functionality and its implications on both data
> integrity and performance.

Yeah, thats right Daniel. I know, we developers and designers don't design and consider and test and retest the code produced from those mini projects to build code that builds those things. We just build those things and deploy them to production the next day. Yep. That's why we are still employed. We produce lots of work, no matter what the quality.

-- 
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.