[DUG] Stored procedures and business logic

[Kyley Harris]

>firstly I make the distinction in the respect that a change in business

>rules should not alter your ri, the difference is breaking ri would 
>result in "what the sh#t is this", breaking business rules results in 
>"should we be allowing this sh#t"

I agree. Referential integrity is about datacorruption, such as keys
that don't point to anything.

Business logic is all about how the user wants to interact with the
data. This can be fluid and change all the time, but the data integrity
(ri) should never change. 

>Its basically the same mismatch that exists between an OO system and a 
>Relational Database, it all goes away if you accept/assume that a row
of 
>a table is a class instance persisted, the question is should you?

Agreed. My system only works for our own products where we put a sticker
over the database "Warrany void if torn". We provide read only access to
others if necessary. If you want to write, go through the middletier. If
you need to work with or write applications that talk to databases that
other people are also talking to then the only way to get a working OO
approach is to to what Java and others do, and define high level XML(or
whatever) metadata dictionaries to represent how you interact with a
relational-db at an 00 level. 

If you are wanting to write a database that is open to anyone for access
then you would have to take rohits approach of stored procedure access
only to maintain both data integrity, and logical integrity.



-----Original Message-----
From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz]
On Behalf Of Neven MacEwan
Sent: Friday, 2 June 2006 12:19 p.m.
To: karlreynolds at xtra.co.nz; NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Stored procedures and business logic

Karl

All the constraint/ri ui code can a) be extracted out of the DB or b) be

autogenerated from metadata

 > Where does referential integrity end and business logic begin anyway?

firstly I make the distinction in the respect that a change in business 
rules should not alter your ri, the difference is breaking ri would 
result in "what the sh#t is this", breaking business rules results in 
"should we be allowing this sh#t"

Its basically the same mismatch that exists between an OO system and a 
Relational Database, it all goes away if you accept/assume that a row of

a table is a class instance persisted, the question is should you?

Neven