Subject | 81 triggers for 27 tables - overkill? |
---|---|
Author | csswa |
Post date | 2002-05-02T18:05:55Z |
Hi all.
I have 81 triggers for a db. Some auto-generate PKs. Some ensure
entered values are uppercase by doing a before insert/update:
new.fieldname = upper(new.fieldname).
Other triggers do various other bits 'n pieces like generating and
checking values (complex checking that I can't do with a constraint).
A lot of these are duplicated triggers, that is they need to fire
both for insert and update.
I've considered merging single triggers into their update type group
(all table before-update trigs into one trig, etc.), but some I want
to be able to switch off certain triggers.
What is common practice for you? For each table, do you try to roll
your before-insert (or whatever) triggers into one before-insert
trigger or do you leave them individually defined? It makes for
neater, easier-managed code to roll each table trigger type into one
section, but this means ALTERing the trigger each time you want to
switch some part of the trigger off, compared to a simple SET
INACTIVE.
To illustrate:
create trigger tr_table1_gen_pk for t_table1
before insert as
... if null, assign the pk from gen ...
create trigger tr_table1_uppercase for t_table1
before insert as
... make some fields uppercase ...
create trigger tr_table1_calc_fields for t_table1
before insert as
... do complex computation of some fields and assign them to
new.field ...
rolled into:
create trigger tr_table1_BI for t_table1
before insert as
... if null, assign the pk from gen ...
... make some fields uppercase ...
... do complex computation of some fields and assign them to
new.field ...
Regards,
Andrew Ferguson
-- What do we have to do to sell you a car today?
I have 81 triggers for a db. Some auto-generate PKs. Some ensure
entered values are uppercase by doing a before insert/update:
new.fieldname = upper(new.fieldname).
Other triggers do various other bits 'n pieces like generating and
checking values (complex checking that I can't do with a constraint).
A lot of these are duplicated triggers, that is they need to fire
both for insert and update.
I've considered merging single triggers into their update type group
(all table before-update trigs into one trig, etc.), but some I want
to be able to switch off certain triggers.
What is common practice for you? For each table, do you try to roll
your before-insert (or whatever) triggers into one before-insert
trigger or do you leave them individually defined? It makes for
neater, easier-managed code to roll each table trigger type into one
section, but this means ALTERing the trigger each time you want to
switch some part of the trigger off, compared to a simple SET
INACTIVE.
To illustrate:
create trigger tr_table1_gen_pk for t_table1
before insert as
... if null, assign the pk from gen ...
create trigger tr_table1_uppercase for t_table1
before insert as
... make some fields uppercase ...
create trigger tr_table1_calc_fields for t_table1
before insert as
... do complex computation of some fields and assign them to
new.field ...
rolled into:
create trigger tr_table1_BI for t_table1
before insert as
... if null, assign the pk from gen ...
... make some fields uppercase ...
... do complex computation of some fields and assign them to
new.field ...
Regards,
Andrew Ferguson
-- What do we have to do to sell you a car today?