[DUG] Stored procedures and business logic

Wed Jun 7 14:59:50 NZST 2006

Expert Engines - will do - thanks.

On 07/06/06, Kyley Harris <kyley at harrissoftware.com> wrote:
>
>   Well. I think WC3 would point you towards a XML style representation of
> SQL Querying and XML row sets, using schema validation to assert the
> correctness of requests sent and data received.
>
>
>
> Mediated through alterable rules is really the trick. This can mean so
> many things. There must be constraints on the alterable rules that all sides
> know about. Have you looked at Expert Engines?
>
>
>  ------------------------------
>
> *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 1:36 p.m.
>
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] Stored procedures and business logic
>
>
>
> 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
>
>
>
>
>
> _______________________________________________
> 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/fe2a066e/attachment-0001.html