[DUG] Stored procedures and business logic

[Paul A Norman]

"To me it is non sensical to put business logic/rules/objects whatever the
term you want to use, in the database. "

I have come to completely agree with that. I believe that may be true for
the conceptual reasons I posted before.

What needs to be stored is an abstraction of the rules (XMLed?), and I
suspect that needs to be designed to check a central registry to see if
there are any *carefully *conceived revisions.

What I am thinking of is abstraction of the application's data needs client
side, and implementation of a server side abstraction, and a common set of
rules for the two abstraction *interfaces* for want of a better word, to
operate and do their stuff  under.

Clinet interface <-> client side data abstraction <- *mediated through
alterable rules*  - > server side data abstraction <-> server database
storage

This will let me have any dataset within reason on the client side.

It seems simillar to aspects of the VM concept.

Is there a recomendation (e.g. WC3) any where on the format for "mediated
through alterable rules" nothing has jumped oput at me yet. How is the Java
one mentioned earlier done  - is that standards based?

I am facing the begining of the development of a larger application at the
moment that has got me really focussed to be very careful on all of this
before I get  too deeply into it.

Some of the folk who are using it may be on linux and on flavours not
conducive to Kylix.

Hence on the Windows environment I am looking at leveraging Delphi with the
php(for)Delphi approach and relying on straight PHP under linux. This may
mean that Windows users will end up with better interfaces (possible more
advanced features), but I can use common "business logic" etc  through
PHP *with
Delphi able to easily write new modules for PHP*.

Further the database will be distributed in that it is to enbale "nodes" of
datasets (holding wider info) to intersect when they are available on line.

I've looked at many Open Source projects and learned a lot from them, but
not quite found something that is going to keep all my people happy (either
as is or readily alterable).

So I am left with ascertaining this befoire I leap off into it. Is there a
recomendation (e.g. WC3) any where on the format for "mediated through
alterable rules"

Paul


On 07/06/06, James Sugrue <jamessugrue at xtra.co.nz> wrote:
>
>   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
>
>
>
>
> _______________________________________________
> 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/0339a8c2/attachment-0003.html