Re: Question on Insert Trigger
From: Serge Rielau <srielau_at_ca.ibm.com>
Date: Mon, 10 Mar 2008 08:00:48 -0400
Message-ID: <63km7iF28186kU1@mid.individual.net>
>
> There you go Serge proving me correct yet again. Ignoring my input
> would be SENSIBLE ... not SENSITIVE. That rule should definitely
> be hard coded.
>
>
> Not business rules. Business rules are things such as don't let
> the person exceed their credit limit. Don't create a duplicate
> account number. Now you might want to configure today's interest
> rate as a package variable captured by the package initialization
> section but it is a value ... not a rule. The "rule" would be to
> apply it to all transactions.
>
>
> Yes though that is not the only reason they are used.
>
>
> Not at all. But given the choice of enforcing a busines rule with a
> constraint or a trigger I would choose the constraint every time if
> it would suffice.
>
>
> It is not a question of one or the other. It is a question of using the
> most efficient solution given the business problem. The most efficient
> is rarely the most complex. Are you suggesting that you are going to
> drop primary key constraints from DB2 in favor of triggers because one
> solution is good enough for all situations? <g>
My post and comments were clear. No need to follow your twisted interpretation of it. Aside why do you keep bringing DB2 up? This is an Oracle NG. Is it possible to have an SQL discussion in this group with you around?
Date: Mon, 10 Mar 2008 08:00:48 -0400
Message-ID: <63km7iF28186kU1@mid.individual.net>
DA Morgan wrote:
> Serge Rielau wrote:
>> DA Morgan wrote: >>> But I am wondering ... would you use a package variable, when >>> you get them into DB2, to enforce a business rule? >> Ah why not? Depends on your rule. >> >> E.g. if I have a rule that says: Ignore all input provided by user >> DAMORGAN that seems like a sensitive thing to do.
>
> There you go Serge proving me correct yet again. Ignoring my input
> would be SENSIBLE ... not SENSITIVE. That rule should definitely
> be hard coded.
>
>> Rules can be user dependent, can they not?
>
> Not business rules. Business rules are things such as don't let
> the person exceed their credit limit. Don't create a duplicate
> account number. Now you might want to configure today's interest
> rate as a package variable captured by the package initialization
> section but it is a value ... not a rule. The "rule" would be to
> apply it to all transactions.
>
>> You like to point out that certain products fail to provide BEFORE >> TRIGGERs. Aren't before triggers used to enforce business rules?
>
> Yes though that is not the only reason they are used.
>
>> By claiming that constraints suffice you say BEFORE TRIGGERs are not >> needed and you bite your own proverbial tail.
>
> Not at all. But given the choice of enforcing a busines rule with a
> constraint or a trigger I would choose the constraint every time if
> it would suffice.
>
>> BEFORE TRIGGERs are used where CHECK CONSTRAINTs fail, such as looking >> at data in different tables, or looking up variable content.
>
> It is not a question of one or the other. It is a question of using the
> most efficient solution given the business problem. The most efficient
> is rarely the most complex. Are you suggesting that you are going to
> drop primary key constraints from DB2 in favor of triggers because one
> solution is good enough for all situations? <g>
My post and comments were clear. No need to follow your twisted interpretation of it. Aside why do you keep bringing DB2 up? This is an Oracle NG. Is it possible to have an SQL discussion in this group with you around?
Cheers
Serge
-- Serge Rielau DB2 Solutions Development IBM Toronto LabReceived on Mon Mar 10 2008 - 07:00:48 CDT