<div>Looks very worth exploring thank you Keith,</div>
<div>paul<br><br> </div>
<div><span class="gmail_quote">On 07/06/06, <b class="gmail_sendername"><a href="mailto:kaller@ihug.co.nz">kaller@ihug.co.nz</a></b> <<a href="mailto:kaller@ihug.co.nz">kaller@ihug.co.nz</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Here's an XML representation courtesy of IBM<br><a href="http://www.alphaworks.ibm.com/tech/commonrules">http://www.alphaworks.ibm.com/tech/commonrules
</a><br>alphaWorks : CommonRules : Overview<br>keith<br><br><br>> Expert Engines - will do - thanks.<br>><br>> On 07/06/06, Kyley Harris <<a href="mailto:kyley@harrissoftware.com">kyley@harrissoftware.com</a>>
<br>> wrote: ><br>> > Well. I think WC3 would point you towards a XML style<br>> > representation of SQL Querying and XML row sets, using<br>> > schema validation to assert the correctness of requests
<br>> sent and data received. ><br>> ><br>> ><br>> > Mediated through alterable rules is really the trick.<br>> > This can mean so many things. There must be constraints<br>> > on the alterable rules that all sides know about. Have
<br>> you looked at Expert Engines? ><br>> ><br>> > ------------------------------<br>> ><br>> > *From:* <a href="mailto:delphi-bounces@ns3.123.co.nz">delphi-bounces@ns3.123.co.nz</a><br>> > [mailto:
<a href="mailto:delphi-bounces@ns3.123.co.nz">delphi-bounces@ns3.123.co.nz</a>] *On Behalf Of<br>> > *Paul A Norman *Sent:* Wednesday, 7 June 2006 1:36 p.m.<br>> ><br>> > *To:* NZ Borland Developers Group - Delphi List
<br>> > *Subject:* Re: [DUG] Stored procedures and business<br>> logic ><br>> ><br>> ><br>> > opps Sorry,<br>> ><br>> ><br>> ><br>> > This will let me have any dataset within reason on the
<br>> client side ><br>> > should be . . .<br>> ><br>> > This will let me have any dataset within reason on the<br>> server side ><br>> ><br>> ><br>> ><br>> ><br>> > On 07/06/06, *Paul A Norman* <
<a href="mailto:paul.a.norman@gmail.com">paul.a.norman@gmail.com</a>><br>> wrote: ><br>> > "To me it is non sensical to put business<br>> > logic/rules/objects whatever the term you want to use,
<br>> in the database. " ><br>> > I have come to completely agree with that. I believe<br>> > that may be true for the conceptual reasons I posted<br>> before. ><br>> ><br>> ><br>
> > What needs to be stored is an abstraction of the rules<br>> > (XMLed?), and I suspect that needs to be designed to<br>> > check a central registry to see if there are any<br>> *carefully *conceived revisions. >
<br>> ><br>> ><br>> > What I am thinking of is abstraction of the<br>> > application's data needs client side, and implementation<br>> > of a server side abstraction, and a common set of rules
<br>> > for the two abstraction *interfaces* for want of a<br>> better word, to operate and do their stuff under. ><br>> ><br>> ><br>> > Clinet interface <-> client side data abstraction <-
<br>> > *mediated through alterable rules* - > server side data<br>> > abstraction <-> server database storage<br>> ><br>> ><br>> ><br>> > This will let me have any dataset within reason on the
<br>> client side. ><br>> ><br>> ><br>> > It seems simillar to aspects of the VM concept.<br>> ><br>> ><br>> ><br>> > Is there a recomendation (e.g. WC3) any where on the<br>
> > format for "mediated through alterable rules" nothing<br>> > has jumped oput at me yet. How is the Java one mentioned<br>> earlier done - is that standards based? ><br>> ><br>> >
<br>> > I am facing the begining of the development of a larger<br>> > application at the moment that has got me really<br>> > focussed to be very careful on all of this before I get<br>> too deeply into it. >
<br>> ><br>> ><br>> > Some of the folk who are using it may be on linux and on<br>> > flavours not conducive to Kylix.<br>> ><br>> ><br>> ><br>> > Hence on the Windows environment I am looking at
<br>> > leveraging Delphi with the php(for)Delphi approach and<br>> > relying on straight PHP under linux. This may mean that<br>> > Windows users will end up with better interfaces<br>> (possible more advanced features), but I can use common
<br>> > "business logic" etc through PHP *with Delphi able to<br>> easily write new modules for PHP*. ><br>> ><br>> ><br>> > Further the database will be distributed in that it is<br>
> > to enbale "nodes" of datasets (holding wider info) to<br>> > intersect when they are available on line.<br>> ><br>> ><br>> ><br>> > I've looked at many Open Source projects and learned a
<br>> > lot from them, but not quite found something that is<br>> > going to keep all my people happy (either as is or<br>> readily alterable). ><br>> ><br>> ><br>> > So I am left with ascertaining this befoire I leap off
<br>> > into it. I s there a recomendation (e.g. WC3) any where<br>> > on the format for "mediated through alterable rules"<br>> ><br>> ><br>> ><br>> > Paul<br>> ><br>> >
<br>> ><br>> > On 07/06/06, *James Sugrue* <<a href="mailto:jamessugrue@xtra.co.nz">jamessugrue@xtra.co.nz</a> ><br>> wrote: ><br>> > Anyone struggling with the concepts of n-tier apps and<br>
> > how to put in to practice could do worse than watch the<br>> following webcast series ><br>> ><br>> ><br>> ><br>> <a href="http://www.microsoft.com/events/series/modernsoftdev.mspx">http://www.microsoft.com/events/series/modernsoftdev.mspx
</a><br>> > ><br>> ><br>> > while it focuses on .NET the principals can be applied<br>> > to any language/platform.<br>> ><br>> ><br>> ><br>> > To me it is non sensical to put business
<br>> > logic/rules/objects whatever the term you want to use,<br>> > in the database. One of the major points of n-tier<br>> design is to allow change of one component of an app<br>> > without effecting the rest. What happens to your
<br>> > business rules if your client decides to change to<br>> another database vendor or decides that they want to run<br>> > disconnected so you need to use XML? Which is another<br>> > reason incidentally why a lot of people are using web
<br>> services in there middle tier…. ><br>> ><br>> > ------------------------------<br>> ><br>> > *From:* <a href="mailto:delphi-bounces@ns3.123.co.nz">delphi-bounces@ns3.123.co.nz</a><br>> > [mailto:
<a href="mailto:delphi-bounces@ns3.123.co.nz">delphi-bounces@ns3.123.co.nz</a>] *On Behalf Of<br>> > *Paul A Norman *Sent:* Wednesday, 7 June 2006 10:48 a.m.<br>> > *To:* NZ Borland Developers Group - Delphi List
<br>> ><br>> ><br>> > *Subject:* Re: [DUG] Stored procedures and business<br>> logic ><br>> ><br>> ><br>> > I'm coming in late on this thread having really valued<br>> > following the discussion.
<br>> ><br>> ><br>> ><br>> > Much of the difficulty in this area focusses around the<br>> > simple thought that wrong things may be attempted on the<br>> > db. And that the DB should do some of the thinking for
<br>> > the application. So much of the logic applied server<br>> side is designed to sort that out. ><br>> ><br>> ><br>> > Is there any appeal to objective philosophical logic<br>> > that points to any overall approach that spares us the
<br>> > intellectual burden of having to trouble shoot problems<br>> and that perhaps should not exist or matters that need to<br>> > be solved serverside?<br>> ><br>> ><br>> ><br>> > Knuth and other early logicticians propose what became
<br>> > simply termed the "rubbish in rubbish out" principle. It<br>> > seems that in flow dynamics it is better to sort rubbish<br>> > out before it goes "down stream", so that you avoid
<br>> having to send anything "up stream" calling for changes. ><br>> ><br>> ><br>> > Many people of that era thinking through this stuff held<br>> > the thought that each isloatible unit should have its
<br>> > own integrity. Hance Knuth's TeX approach in page layout<br>> > which is in its own way, the storage and qualifying of<br>> data. The format of TeX assumes though that the 'user' has<br>> > already pre-processed the actual data and it is
<br>> warrantable for deployment. ><br>> ><br>> ><br>> > So I have been thinking alot about this stuff from the<br>> > view that each level of the process should only be<br>> > passing 'data' on to the next that is in all senses pure
<br>> > and appropriate. Now people will immeadiatley say that<br>> can not work for multi-development-client applications<br>> > utilising a common database.<br>> ><br>> ><br>> ><br>> > To that I would make the suggestion of a server
<br>> > abstraction layer which requires that an application<br>> > must send a verifying "key" that asserts that the post<br>> has the integrity required by the standard set for the<br>> > process. Not just a password alone, the purpose being to
<br>> > focuss the developer to implement internally all<br>> > necessary requirements prior to posting. These<br>> requirements can available following the Java strategy<br>> pointed out earlier. ><br>
> ><br>> ><br>> ><br>> > Perhaps then logic and checks db side should only be as<br>> > minimal as possible - essential enough to ensure the<br>> > basic integrity of the db is actually maintained.
<br>> ><br>> ><br>> ><br>> > Would this perhaps effectively build applications which<br>> > were to a high degree abstractable from the underlying<br>> database in use? ><br>> ><br>
> ><br>> > Paul<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > On 07/06/06, *Neven MacEwan* < <a href="mailto:neven@mwk.co.nz">neven@mwk.co.nz</a>> wrote:<br>> ><br>> > Kurt
<br>> ><br>> > I have to agree with Kyley that clearly the definition<br>> > of a business rule is in dispute. This reminds me that a<br>> > few years ago I tried to find a definition of a<br>> > 'business object' and only suceeded in finding what it
<br>> wasn't, namely a row of data in a RDB. Also by your<br>> > definition you could implement all business rules in the<br>> > RDB, which you can't! for example a business may have<br>> > well defined rules for resolving a many-to-many
<br>> relationship (The most common implementation of this is an<br>> > open item transaction ledger) but the best the RDB can<br>> you is enforce RI. ><br>> > I call the rules that protected the data DI (Data
<br>> > Integrity) this covers RI, Constraints, Calculated<br>> > Columns (Intra Row and Aggregated) you can include State<br>> > Checking (ie we cannot edit this record as it is<br>> locked). But in my experience as much as you put in the DB
<br>> > you cannot implement a business there IMHO<br>> ><br>> > Neven<br>> ><br>> ><br>> ><br>> ><br>> > kurt wrote:<br>> > > Neven MacEwan wrote:<br>> > >> All the constraint/ri ui code can a) be extracted out
<br>> > of the DB or b) >> be autogenerated from metadata<br>> > >><br>> > >> > Where does referential integrity end and business<br>> > logic begin anyway?<br>> > ><br>
> > > - a database is a collection of constraints<br>> > > - a business rule is a constraint<br>> > ><br>> > >> firstly I make the distinction in the respect that a<br>> > change in >> business rules should not alter your ri,
<br>> > the difference is breaking ri >> would result in "what<br>> > the sh#t is this", breaking business rules >> results in<br>> > "should we be allowing this sh#t" >
<br>> > ><br>> > > I don't see the difference : referential integrity is<br>> > > one (the most common) way of implementing business<br>> > rules. ><br>> > > "unique index on client ID" is a simple RI statement,
<br>> > > that enforces the rule that client ID's are unique<br>> > > within that set of data, no?<br>> > ><br>> > ><br>> > >> Its basically the same mismatch that exists between
<br>> > an OO system and a >> Relational Database, it all goes<br>> > away if you accept/assume that a row >> of a table is a<br>> > class instance persisted, the question is should you? >
<br>> > > Nope. Class = Type ;)<br>> > ><br>> > ><br>> > > Cheers, Kurt.<br>> > > _______________________________________________<br>> > > Delphi mailing list<br>> > >
<a href="mailto:Delphi@ns3.123.co.nz">Delphi@ns3.123.co.nz</a><br>> > > <a href="http://ns3.123.co.nz/mailman/listinfo/delphi">http://ns3.123.co.nz/mailman/listinfo/delphi</a><br>> > ><br>> > ><br>
> ><br>> > --<br>> > Neven MacEwan ( B.E. E&E)<br>> > Ph. 09 620 1356 Mob. 027 4749 062<br>> ><br>> > New Address Details<br>> > ==================><br>MWK Computer Systems
<br>> > 1 Taumata Rd<br>> > Sandringham<br>> > Auckland<br>> ><br>> > Ph 620 1356<br>> > Fx 620 1336<br>> ><br>> ><br>> > _______________________________________________
<br>> > Delphi mailing list<br>> > <a href="mailto:Delphi@ns3.123.co.nz">Delphi@ns3.123.co.nz</a><br>> > <a href="http://ns3.123.co.nz/mailman/listinfo/delphi">http://ns3.123.co.nz/mailman/listinfo/delphi
</a><br>> ><br>> ><br>> ><br>> ><br>> > _______________________________________________<br>> > Delphi mailing list<br>> > <a href="mailto:Delphi@ns3.123.co.nz">Delphi@ns3.123.co.nz
</a><br>> > <a href="http://ns3.123.co.nz/mailman/listinfo/delphi">http://ns3.123.co.nz/mailman/listinfo/delphi</a><br>> ><br>> ><br>> ><br>> ><br>> ><br>> > _______________________________________________
<br>> > Delphi mailing list<br>> > <a href="mailto:Delphi@ns3.123.co.nz">Delphi@ns3.123.co.nz</a><br>> > <a href="http://ns3.123.co.nz/mailman/listinfo/delphi">http://ns3.123.co.nz/mailman/listinfo/delphi
</a><br>> ><br>> ><br>> ><br>><br>><br>> _______________________________________________<br>> Delphi mailing list<br>> <a href="mailto:Delphi@ns3.123.co.nz">Delphi@ns3.123.co.nz</a><br>>
<a href="http://ns3.123.co.nz/mailman/listinfo/delphi">http://ns3.123.co.nz/mailman/listinfo/delphi</a><br>><br><br>_______________________________________________<br>Delphi mailing list<br><a href="mailto:Delphi@ns3.123.co.nz">
Delphi@ns3.123.co.nz</a><br><a href="http://ns3.123.co.nz/mailman/listinfo/delphi">http://ns3.123.co.nz/mailman/listinfo/delphi</a><br></blockquote></div><br>