[DUG] Why InterBase

Neven MacEwan neven at mwk.co.nz
Fri Jun 2 09:53:51 NZST 2006


[KC]urt

This approach is fine for a bespoke app (1 implementation) but really 
comes unstuck if you are writing an app for a wider market (like a set 
of financials with 100's of implementations), You will eventually hit a 
requirement which will push

a) The bounds of what the db server is capable of enforcing regards 
behaviour set by 'configuration'

b) Because the DB Server enforces the rules you have to have the UI 
guiding the user otherwise its a 'chuck at the db and see what happens' 
UI (ughh). if you do this then you have duplication in business logic 
(in the ui and the db) and therefore the inevitability of errors

IMHO (so as not to upset Alan again)

Neven

kurt wrote:
> Kyley Harris wrote:
>> I agree. I actually don't put ANY business logic into the database. 
> 
> Urk, disagree.
> Database is almost pure business logic already
> (there shall be 3 addresses per client, and one shall be called
> the contact address).
> Only reasons for pulling stuff out are SQL's limited expression,
> micro-managing performance (manipulating all the X's for
> this Y only), and fitting a different logical structure on top
> of the data.
> 
> OTOH, I've not met another programmer that agrees with me yet :)
> 
> Cheers, Kurt.
> 
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
> 
> 

-- 
Neven MacEwan (B.E. E&E)
Ph. 09 620 1356 Mob. 027 4749 062

New Address Details
===================
MWK Computer Systems
1 Taumata Rd
Sandringham
Auckland

Ph 620 1356
Fx 620 1336
-------------- next part --------------
A non-text attachment was scrubbed...
Name: neven.vcf
Type: text/x-vcard
Size: 164 bytes
Desc: not available
Url : http://ns3.123.co.nz/pipermail/delphi/attachments/20060602/7775e43b/neven.vcf


More information about the Delphi mailing list