[DUG] Stored procedures and business logic
Kyley Harris
kyley at harrissoftware.com
Wed Jun 7 14:04:54 NZST 2006
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 <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns3.123.co.nz/pipermail/delphi/attachments/20060607/937551e4/attachment-0001.html
More information about the Delphi
mailing list