[DUG] Stored procedures and business logic

[Paul A Norman]

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/72f618e3/attachment.html