[DUG] Stored procedures and business logic

Wed Jun 7 13:36:24 NZST 2006

opps Sorry,

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

should be . . .
This will let me have any dataset within reason on the server side

On 07/06/06, Paul A Norman <paul.a.norman at gmail.com> wrote:
>
>  "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. I s 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/5927883f/attachment-0001.html