Re: You have my sympathies

On Wed, 15 Mar 2000 19:02:12 -0000, "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote:

>
>Still taking the position of the devil's advocate
>here - this bit of 'data integrity' is not an inherent
>requirement of the data when viewed from
>the perspective of the database

Oh yes it is! Data is stored in the database, which is assigned to take care of its integrity not only in the physical level but also logical.

>
>Arguably the purpose of the database is to
>ensure that if I put in 1 customer and 5 orders
>they all go in or nothing goes in, and if I join
>two tables on a given column then the
>results appear as expected.

And to ensure that if you put a new customer John Doe and 5 orders from him, they don't end up (part or whole) assigned to customer Betty Fonebone.

Which is possible if you don't put that rule in the database and leave it to a coder to "not forget to do"... The database will in that case religiously save 1 customer and 5 orders. But all mixed up.

Fully recoverable, though... ;-)

>
>The fact that the business layer will only
>allow orders to go in if a related customer
>exists is not a piece of information that
>the database needs to know.

Oh yes it is. That's got nothing to do with business rules and everything to do with logical data integrity rules. Please read on for a true business rule coming up.

>
>(And, of course, if the only code to insert
>and delete data comes from the business
>layer,

Says who? Better yet: ensures who? That is the whole reason for putting logical data integrity rules in the database: NOBODY can ensure to you that is the case UNLESS the rule lives in the database.

> (as it no doubt will ;)

Yeah, right! :-) Tell that to the guys who had to maintain old flat file-based applications...

>then the business
>rules about customers will say that a
>customer may only be removed from the
>business if they have placed no orders.

Not necessarily. The data integrity rules may say that, and the database should enforce it.

But the business rules should instead say: a customer with no orders should receive heaps of advertising.

A perfect example where a business rule is not necessary in the database.

It's a functional rule, not a data integrity rule. Therefore it BELONGS in the business layer. The data integrity rule IS for the database.

>So the database does not need to
>duplicate the code built in to the
>business layer).

Correct. 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.

And a lot less network load. Which allows you to plonk the business layer away from the data layer and the presentation layer. More flexibility, better final system.

Don't even try to do that with a model that says all rules belong in the business layer. That is analogous to going back to the old mainframe application days, where the thin client was the block-mode terminal, the application layer was that horrible lump of Cobol code that nobody did understand and the data was amorphous flat filed and (in 99% of the cases) totally corrupt in the logical sense.

In fact, if you look at the 3-tier commercial applications out there that do just this, guess what? They are ALL, without exception, straight ports of applications that used to run in mainframes against flat files. Funny that, ain't it? <d&r>

With the worse problem now that the connection between the application server and the data server is not shared memory but relatively s-l-o-w net wire.

Please read my other reply, it complements this one as well as vicky-the-versa.

Cheers
Nuno Souto
nsouto_at_nsw.bigpond.net.au.nospam
http://www.users.bigpond.net.au/the_Den/index.html Received on Thu Mar 16 2000 - 00:00:00 CST