| Robert 2007-10-12, 3:55 am |
| On Fri, 12 Oct 2007 14:24:40 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
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.
The exception is reports, which can be kept up to date automatically by materialized
views.
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.
|