Re: "All triggers are evil",..., really?

From: Niall Litchfield <niall.litchfield_at_gmail.com>
Date: Thu, 21 Aug 2008 16:39:41 +0100
Message-ID: <7765c8970808210839q49f3ac2eu683ca2d4acdeeb6d@mail.gmail.com>


Toon,

I suspect that for a lot of us this comes back to the old argument of "where do you store business logic" most, if not all data constraints are really business rules - even if not directly expressed as such , "each order line must be associated with an order" is also a business rule for example. It's probably no surprise that I agree with you that the business rules that directly affect data should be stored along with the data, not least because it's likely that other applications will come along that should also be subject to the same business rules. In fact I'd be willing to bet that Tom's name := first_name||' '||last_name example came about precisely because two sets of people hadn't agreed on what the business rules were and isn't really a technology problem at all.

I can see a number of maintenance reasons as to why such code is best stored in api packages rather than triggers but I don't actually see the fact that correctly defining and implementing business rules in PL/SQL such that they still obey the ACID properties in the event of unexpected conditions in a reason to avoid PL/SQL - in fact I'd say the same rule applies in spades to coding business rules in languages away from the data *cough*j2ee*cough*.

Niall

On Thu, Aug 21, 2008 at 4:17 PM, Toon Koppelaars <toon_at_rulegen.com> wrote:

> All other(*) data constraints in my database design.
>
> *: other = other than the ones that I can deal with declaratively.
>
> EMP-DEPT examples:
> - There can be at most one PRESIDENT in EMP table.
> - Everybody has less salary than his/her direct manager.
> - No department can have more than 30 employees.
> - Every department with a MANAGER, should also have an ADMINISTRATOR.
> - ...
> etc.
>
> On Thu, Aug 21, 2008 at 4:11 PM, Clarke, Andrew <andrew.clarke_at_logica.com
> > wrote:
>
>> >> If all constraint validation is correctly 'tucked away' behind
>> triggers, then all
>> >> of your other application code (the 'business logic' code) can be
>> devoid of
>> >> constraint validation code
>>
>> What sort of validation would you want to do which can't be done by
>> declarative constraints and which you also wouldn't want to include in the
>> "'business logic' code"?
>>
>> Cheers, APC
>>
>>
>> A P Clarke
>> Software Architect
>> Logica UK Public Sector Division
>> Stephenson House
>> 75 Hampstead Road
>> London
>> UK
>> NW1 2PL
>> Direct Tel: +44 (0)207 230 3160
>> Fax: +44 (0)207 446 1352
>> Email: andrew.clarke_at_logica.com
>>
>>
>> This e-mail and any attachment is for authorised use by the intended
>> recipient(s) only. It may contain proprietary material, confidential
>> information and/or be subject to legal privilege. It should not be copied,
>> disclosed to, retained or used by, any other party. If you are not an
>> intended recipient then please promptly delete this e-mail and any
>> attachment and all copies and inform the sender. Thank you.
>>
>>
>
>
> --
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> Toon Koppelaars
> RuleGen BV
> +31-615907269
> toon_at_rulegen_dot_com
> www_dot_rulegen_dot_com
>
> Author: "Applied Mathematics for Database Professionals"
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Aug 21 2008 - 10:39:41 CDT

Original text of this message