[DUG] Stored procedures and business logic

Wed Jun 7 11:27:26 NZST 2006

Anyone struggling with the concepts of n-tier apps and how to put in to
practice could do worse than watch the following webcast series

http://www.microsoft.com/events/series/modernsoftdev.mspx

while it focuses on .NET the principals can be applied to any
language/platform.

To me it is non sensical to put business logic/rules/objects whatever the
term you want to use, in the database. One of the major points of n-tier
design is to allow change of one component of an app without effecting the
rest. What happens to your business rules if your client decides to change
to another database vendor or decides that they want to run disconnected so
you need to use XML? Which is another reason incidentally why a lot of
people are using web services in there middle tier..

  _____  

From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz] On
Behalf Of Paul A Norman
Sent: Wednesday, 7 June 2006 10:48 a.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Stored procedures and business logic

I'm coming in late on this thread having really valued following the
discussion.

Much of the difficulty in this area focusses around the simple thought that
wrong things may be attempted on the db. And that the DB should do some of
the thinking for the application. So much of the logic applied server side
is designed to sort that out. 

Is there any appeal to objective philosophical logic that points to any
overall approach that spares us the intellectual burden of having to trouble
shoot problems and  that perhaps should not exist or matters that need to be
solved serverside? 

Knuth and other early logicticians propose what became simply termed the
"rubbish in rubbish out" principle. It seems that in flow dynamics it is
better to sort rubbish out before it goes "down stream", so that you avoid
having to send anything "up stream" calling for changes. 

Many people of that era thinking through this stuff held the thought that
each isloatible unit should have its own integrity. Hance Knuth's TeX
approach in page layout which is in its own way, the storage and qualifying
of data. The format of TeX assumes though that the 'user' has already
pre-processed the actual data and it is warrantable for deployment. 

So I have been thinking alot about this stuff from the view that each level
of the process should only be passing 'data' on to the next that is in all
senses pure and appropriate. Now people will immeadiatley say that can not
work for multi-development-client applications utilising a common database. 

To that I would make the suggestion of a  server abstraction layer which
requires that an application must send a verifying "key" that asserts that
the post has the integrity required by the standard set for the process. Not
just a password alone, the purpose being to focuss the developer to
implement internally all necessary requirements prior to posting. These
requirements can available  following the Java strategy pointed out earlier.

Perhaps then logic and checks db side should only be as minimal as possible
- essential enough to ensure the basic integrity of the db is actually
maintained.

Would this perhaps effectively build applications which were to a high
degree abstractable from the underlying database in use?

Paul

On 07/06/06, Neven MacEwan <neven at mwk.co.nz> wrote: 

Kurt

I have to agree with Kyley that clearly the definition of a business
rule is in dispute. This reminds me that a few years ago I tried to find 
a definition of a 'business object' and only suceeded in finding what it
wasn't, namely a row of data in a RDB. Also by your definition you could
implement all business rules in the RDB, which you can't! for example a 
business may have well defined rules for resolving a many-to-many
relationship (The most common implementation of this is an open item
transaction ledger) but the best the RDB can you is enforce RI.

I call the rules that protected the data DI (Data Integrity) this covers 
RI, Constraints, Calculated Columns (Intra Row and Aggregated) you can
include State Checking (ie we cannot edit this record as it is locked).
But in my experience as much as you put in the DB you cannot implement a 
business there IMHO

Neven

kurt wrote:
> Neven MacEwan wrote:
>> 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?
>
>  - a database is a collection of constraints
>  - a business rule is a constraint
>
>> 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 don't see the difference : referential integrity is one
> (the most common) way of implementing business rules.
>
> "unique index on client ID" is a simple RI statement, 
> that enforces the rule that client ID's are unique within
> that set of data, no?
>
>
>> 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?
>
> Nope. Class = Type ;)
>
>
> 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

_______________________________________________ 
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns3.123.co.nz/pipermail/delphi/attachments/20060607/d0bf29db/attachment-0001.html