<div>I'm coming in late on this thread having really valued following the discussion.</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>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?
</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Would this perhaps effectively build applications which were to a high degree abstractable from the underlying database in use?</div>
<div> </div>
<div>Paul</div>
<div><br><br> </div>
<div><span class="gmail_quote">On 07/06/06, <b class="gmail_sendername">Neven MacEwan</b> <<a href="mailto:neven@mwk.co.nz">neven@mwk.co.nz</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Kurt<br><br>I have to agree with Kyley that clearly the definition of a business<br>rule is in dispute. This reminds me that a few years ago I tried to find
<br>a definition of a 'business object' and only suceeded in finding what it<br>wasn't, namely a row of data in a RDB. Also by your definition you could<br>implement all business rules in the RDB, which you can't! for example a
<br>business may have well defined rules for resolving a many-to-many<br>relationship (The most common implementation of this is an open item<br>transaction ledger) but the best the RDB can you is enforce RI.<br><br>I call the rules that protected the data DI (Data Integrity) this covers
<br>RI, Constraints, Calculated Columns (Intra Row and Aggregated) you can<br>include State Checking (ie we cannot edit this record as it is locked).<br>But in my experience as much as you put in the DB you cannot implement a
<br>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 of the DB or b)<br>>> be autogenerated from metadata
<br>>><br>>> > Where does referential integrity end and business 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 change in
<br>>> business rules should not alter your ri, the difference is breaking ri<br>>> would result in "what the sh#t is this", breaking business rules<br>>> results in "should we be allowing this sh#t"
<br>><br>><br>> I don't see the difference : referential integrity is one<br>> (the most common) way of implementing business rules.<br>><br>> "unique index on client ID" is a simple RI statement,
<br>> that enforces the rule that client ID's are unique within<br>> that set of data, no?<br>><br>><br>>> Its basically the same mismatch that exists between an OO system and a<br>>> Relational Database, it all goes away if you accept/assume that a row
<br>>> of a table is a class instance persisted, the question is should you?<br>><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></blockquote>
</div><br>