Subject | Re: [ib-support] 81 triggers for 27 tables - overkill? |
---|---|
Author | Lista de Discução Interbase |
Post date | 2002-05-02T18:45:13Z |
Hi,
I prefer one trigger for each process (the first approach), I think this
way you have a more managable code, each trigger is small enough to be
understand easily, you can change easily with out messing around with a big
code, You do not have to worry if one thing could lead the other to fail,
you can disable each part individualy, etc. And you continue using the KISS
aproach
(Keep It Simple Stupid) ;-).
But, I do not know if having 3 trigger instead of one could cause a
performance decrease. I don't think so.
You do not know how happy I was when I see that IB/FB could have more than
one trigger per operation (insert, delete, update), I have used MSSQL 6.5
and it could only handle one trigger per operation, I have some BIG ones
and it is a pain to do maintenance.
see you
Alexandre
At 18:05 02/05/2002 +0000, you wrote:
I prefer one trigger for each process (the first approach), I think this
way you have a more managable code, each trigger is small enough to be
understand easily, you can change easily with out messing around with a big
code, You do not have to worry if one thing could lead the other to fail,
you can disable each part individualy, etc. And you continue using the KISS
aproach
(Keep It Simple Stupid) ;-).
But, I do not know if having 3 trigger instead of one could cause a
performance decrease. I don't think so.
You do not know how happy I was when I see that IB/FB could have more than
one trigger per operation (insert, delete, update), I have used MSSQL 6.5
and it could only handle one trigger per operation, I have some BIG ones
and it is a pain to do maintenance.
see you
Alexandre
At 18:05 02/05/2002 +0000, you wrote:
>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?
>
>
>
>
>
>To unsubscribe from this group, send an email to:
>ib-support-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/