[DUG] Stored procedures and business logic

Wed Jun 7 17:21:35 NZST 2006

Looks very worth exploring thank you Keith,
paul


On 07/06/06, kaller at ihug.co.nz <kaller at ihug.co.nz> wrote:
>
> Here's an XML representation courtesy of IBM
> http://www.alphaworks.ibm.com/tech/commonrules
> alphaWorks : CommonRules : Overview
> keith
>
>
> > 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
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > 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/350b88de/attachment-0001.html