[DUG] Stored procedures and business logic

[kaller at ihug.co.nz]

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
>