Re: You have my sympathies

On Sat, 18 Mar 2000 22:59:42 -0000, "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote:

>
>and the good pragmatist's viewpoint:
>
> "The problem is separating the rules into what is data"
> "integrity rule and what is a functional rule. "
> "Spread the rules into the layer that executes them better and safer"
> "and you got the perfect solution."

This is a point I come back to often. I don't think there is a good mechanism - or "formalism" if you prefer, to identify exactly what is a data integrity rule and what is a functional rule. Hence the problems with where things go. The first person to come up with a hard and fast formalism to handle this wins the cake, IMO. While that doesn't happen, we all have to live in an imperfect world, I'm afraid.

>
>though I think that having done this most of my
>rules (both types) would be in the database, but I
>would call several of them one at a time, which
>I think might be a little at odds with your approach

Maybe. I tend to identify data integrity rules upfront and stick them to the DB. Pure business functions I don't do that as much. Although PL/SQL is plenty powerful enough to have most of these inside it, I don't think the DB is the right place to do the business layer. Questions of portability of code and such crop up here.

> 3-tier is somehow supposed to split the application
> into
> presentation layer
> business layer
> database layer
>

I think that the problem in this is the "somehow". It is too wide open for my taste. It basically leaves the door wide open to all sorts of bad implementations, 2 or 3 tier notwithstanding.

> I haven't yet come across code in the business
> layer that couldn't be done better by being in the
> (specifically Oracle) database as integrity constraints,
> triggers, or calls to packaged procedures

Here I mildly disagree. I like PL/SQL and its power, but I don't think it can _easily_ handle all sorts of data-entry validations better than a business layer (with whatever language may be used in it).

The thing that worries me is the net traffic. I'd rather have a business layer deal with the "niceties" of presentation than having the database code handle that. If the nitty-gritty of user interaction is kept in the business layer, then we can have many of those sitting on each LAN in a WAN (if that is the right way of expressing the thought, I'm not a network expert!). Each will handle the local traffic and come to the central database for the data-related stuff only.

I guess what I am saying really is: keep the appropriate code in the appropriate layer. Data integrity in the database. Display gizmos in the thin client. The rest of the code in the business layer. Identifying which is which is what "sorts the men from the boys"...

> Most 3rd party applications using the 3-tier model
> use lowest-common-denominator approaches so
> that they can talk to 'any relational database'
> (including flat files !)

Correct. Doesn't mean they are right, it just means they do it.

>
> The world is going wild with CORBA and Javabeans
> where you buy a handful of business-driven code
> components from different people, string them
> together and have an application.
>

I don't think the technology is yet quite there, but that is definitely the way to go to reduce development cycles.

> End-users tend to prefer drop-down lists and instant
> validation to filling in a form and being told 10 seconds
> after they have finished it that the second field is wrong,

That is quite right. It all has to do with the design approach and nothing to do with 2 or 3-tier, database vs. business or whatever.

>
>Is there a newer, least-worst, way of using emergent
>technologies to address the conflicting requirements of
> happy users
> optimal performance
> minimal code maintenance

Hope there is, but I haven't yet found it. :-)

>
>Does this mean that you send the order to the database and
>get a list of all the errors returned, which you then forward to
>the client ? Sounds like a nasty piece of code in the business
>layer.

Nobody said it was easy.... I wouldn't send lists of errors to the client, though! :-D

>Even if you do it the easy way - send the package, get
>just one error message you then have to:
>
> ensure that the business layer and database layer
> know the list of legal error messages

Yes. Store the possible errors in a database table, then make the business layer read them and cache them at startup. Add some code for online re-synch if that is a "must have". What is so bad about that? All 3-tier business apps already do that from their "config" layer anyway.

>
> get the business layer to run through its list along the
> lines of:
> case return code is
> XXX ) do action 1
> YYY) do action 2
> end case

Won't it have to do the same if the rule is in the business layer?

>
>Putting the 'data integrity' rules into the database
>doesn't really remove any duplication in the code,

I does if you have 2 or more business layers talking to same database. Which will always be the case unless we go the way of "one database - one application". Waste of resources, IMHO.

>it just camouflages one copy - if I introduce a new
>business rule 'order must be over 20 pounds' and
>check it in the database (because it is data integrity
>and I can) then I have to 'copy' the check into the
>business code layer, albeit disguised as: 'if error
>99 is returned by the database push a message to
>the presentation layer that the order is too small'.

Not really. You put the new rule in database, you add the error message to the table, and you signal the business layer to re-fresh/re-synch. How you code the error message handling to make this effective is the big secret. Ever wondered why 3-tier makers go "spastic" everytime a client suggests having access to the internal workings of their "config" mechanism? Precisely!....

>
>I also think that your example of John Doe with
>the five orders being a 'proof' that the database
>ought to handle the data integrity is slightly
>suspect. In the hands of the appropriate coder the
>orders could still end up belonging to someone
>else - database integrity ensures only that they
>end up belonging to someone.

Sure. But it would have to be an INTENTIONAL action. The purpose of the data integrity rules is to prevent the accidental, not the intentional. That is a problem for security. IMHO, ORACLE does the best job of any RDBMS in the industry when it comes to both of these, but that is another story.

>
>BTW - what does <d&r> represent ?
>

d&r = Duck & Run.

As in what one does when one says something that is known to cause "ripples" in the "establishment"...

Cheers
Nuno Souto
nsouto_at_nsw.bigpond.net.au.nospam
http://www.users.bigpond.net.au/the_Den/index.html Received on Sat Mar 18 2000 - 21:22:30 CST