It is a part of your knowledge – but in my humble opinion very old-school and batch oriented.

Best regards,

Niels Liisberg

Hi Jim;

It depends on design philosophy… Some Jurassic programmers are using PL-SQL for almost anything – Other will kill you for bringing PL-SQL into their shops – lots of pros and cons.

Same goes for triggers, UDTF's and stores procedures. Some like it under the DB/whatever-hood. Other like to place it in pure logic – Others again are using even more sophisticated approaches and incapsulate all SQL stuff in frameworks and access only the database using objects, so called Object Relation Mapping or just ORM – like in the hibernate framework.

Personally I prefer ORM's and no triggers, no UDTF's and no stored procs. However I'm not fanatic, and at some occasions it makes much more sense to use one or all of the above… Some times you need to break into a monolithic application – this is where triggers fit in. Sometimes you need to invoke logic from remote sites or isolate ugly stuff – this is where stores procs fit on. Some times you need to sort on output from an algorithm – this if where UDTF's comes into the ballgame. The problem, however, is that your business logic is spread all over your data base and it is a mess to debug, and it can be extremely error prone.

Best regards,

Niels Liisberg