Re: OO and IBM z series COBOL was Re: Discussions of COBOLphilospphy



"Robert" <no@xxxxxx> wrote in message
news:7uotg3hr7ilbu09726uatk94hm924n8d65@xxxxxxxxxx
On Fri, 12 Oct 2007 14:24:40 +1300, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

Going for stored procedures is a conceptual shift.

Conceptually it says: " I have this repository with my data on it. Now I'm
going to make it more than just a data storage entity, I'm going to make
it
"smart".

Instead of building the "smartness" into application code, it is inherent
in
the database. The DB is smart enough to provide information derived from
any
number of tables, it can "relate" fields so that when one field is updated
somewhere, another field (or fields) derived from it, or connected to it,
is
calculated (maybe even in another table) and updated also. The
opportunities
are almost infinite.

If it were designed well, it wouldn't need to be smart because it wouldn't
have any
dependencies (except keys). It would be in normal form.

Possibly... I've seen very few live databases with more than a few tables,
that were ever normalized; often redundancy is built back inot them because
some DBA thinks it is a good idea :-)

Even if we had a perfect database, there is still a case for making it
smart. There are functions (particularly with Dates) that are much better
suited to "back end" processing than doing them in application code.

The exception is reports, which can be kept up to date automatically by
materialized
views.

Again, mileage may vary :-)

A GOOD use for triggers is leaving audit trails. When triggers, rather
than applications,
are used, the audit cannot be bypassed by utilities such as SQLPLUS and
TOAD, nor my
misbehaving applications.

Yes, I have used triggers for this purpose when dealing with sensitive data.

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages

  • Re: OO and IBM z series COBOL was Re: Discussions of COBOLphilospphy
    ... going to make it more than just a data storage entity, ... A GOOD use for triggers is leaving audit trails. ... misbehaving applications. ...
    (comp.lang.cobol)
  • RE: Event when Access table is accessed through ODBC ?
    ... But the crucial thing is then is whether and how a change in the database ... Only Client-Server databases, such as SQLServer, ... Oracle, etc, support triggers. ... updated through ODBC? ...
    (microsoft.public.access.modulesdaovba)
  • Having Trouble with triggers!! ~ Please Help!
    ... master database and three satellite using triggers. ... server to be used as my remote satellite test. ... the stored procedure, right?!... ...
    (microsoft.public.sqlserver.replication)
  • RE: Event when Access table is accessed through ODBC ?
    ... But the crucial thing is then is whether and how a change in the database ... Only Client-Server databases, such as SQLServer, ... Oracle, etc, support triggers. ... updated through ODBC? ...
    (microsoft.public.access.modulesdaovba)
  • Re: Advice sought on use of DTS [Long]
    ... it may help to know that you can disable triggers temporarily do ... You may want to set up a sql job to copy over the remote database (the ... Can you programmatically tell a DTS package which databases to update? ...
    (microsoft.public.sqlserver.dts)
Loading