trigger vs. application code performance

[robert]

typed this into the ibm.com search window, but didn't get anything
that looked like it would answer a question:

+trigger +faster +db2 +cobol
the question: are DB2 (390/v6, at the moment) triggers better
or worse (and how much so, of course) than the same functionality
coded in COBOL? assuming, of course, equal competence in the code.

conventional wisdom, as received, is that triggers are worse, given
that they are 'interpreted' on each invocation. tried about the same
input to the Redbooks search and got 0 hits. hmmm. seems like a basic
question for which IBM would have a ready answer.

(tried the same input to this group. nuthin. more hmmmmm.)

thanks,
robert

[Anton Versteeg]

If you leave out +Cobol you will get hundreds of hits.

To answer your question: it probably depends on
- For instance is your Cobol appl running on the same host as DB2 or
remotely via DB2 Connect?
- what you are doing in your trigger

And of course you probably realize that using a trigger might save you a
lot of code if you have more that one application updating/inserting
into that table.

robert wrote:

typed this into the ibm.com search window, but didn't get anything
that looked like it would answer a question:

+trigger +faster +db2 +cobol
the question: are DB2 (390/v6, at the moment) triggers better
or worse (and how much so, of course) than the same functionality
coded in COBOL? assuming, of course, equal competence in the code.

conventional wisdom, as received, is that triggers are worse, given
that they are 'interpreted' on each invocation. tried about the same
input to the Redbooks search and got 0 hits. hmmm. seems like a basic
question for which IBM would have a ready answer.

(tried the same input to this group. nuthin. more hmmmmm.)

thanks,
robert

[robert]

Anton Versteeg <an************ @nnll.ibm.com> wrote in message news:<c5******* ****@sp15en20.h ursley.ibm.com> ...

If you leave out +Cobol you will get hundreds of hits.

To answer your question: it probably depends on
- For instance is your Cobol appl running on the same host as DB2 or
remotely via DB2 Connect?
- what you are doing in your trigger

And of course you probably realize that using a trigger might save you a
lot of code if you have more that one application updating/inserting
into that table.
oh yeah. but my opponents (who wrote the system in COBOL/VSAM/CICS in
the '70s) in this exercise assert that COBOL is faster. period.

one database <-> one application

in this case, yes the COBOL is on the same host. and the tables are,
in
general, not in first normal form.

what i'm looking for, and neither the titles nor the summaries jumped
out at me, is a description of the trigger execution model and a
comparison to native code (whether COBOL, C, or java). so, is it true
that triggers are stored as text, translated to p-code on first
call, and interpreted by a p-code engine on each subsequent call? or
are they stored as text, compiled to native code on first call, then
executed by an O/S process after that?

and so on. not that i'm looking to someone in the group to type
all that; rather a reference to a white paper or redbook or article
describing how they actually work.

thanks,
robert


robert wrote:

typed this into the ibm.com search window, but didn't get anything
that looked like it would answer a question:

+trigger +faster +db2 +cobol
the question: are DB2 (390/v6, at the moment) triggers better
or worse (and how much so, of course) than the same functionality
coded in COBOL? assuming, of course, equal competence in the code.

conventional wisdom, as received, is that triggers are worse, given
that they are 'interpreted' on each invocation. tried about the same
input to the Redbooks search and got 0 hits. hmmm. seems like a basic
question for which IBM would have a ready answer.

(tried the same input to this group. nuthin. more hmmmmm.)

thanks,
robert