[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
[email protected]
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
begin:vcard
fn:Neven MacEwan
n:MacEwan;Neven
email;internet:[EMAIL PROTECTED]
tel;work:649 620 1356
tel;fax:649 620 1336
tel;cell:0274 749 062
version:2.1
end:vcard
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
