Re: Database Design Question - any suggestion?

Celko:

An interesting use of artificial confusion:

"-CELKO-" <jcelko212_at_earthlink.net> wrote in message news:1102628203.603305.256220_at_f14g2000cwb.googlegroups.com...

[stuff snipped]

> 3) The problem with trusting just the front end to do the checking is
> that you have made a leap of faith that:
>
> a) All current programmers know **and agree upon** ALL the business
> rules. That is, Peter reads "employees must be 18 years of age or
> older" as (age > 18) and Paul reads it as (age >= 18) and you're in
> trouble.

A couple of points here:

1. When a business application's business rules are "agreed upon" by programmers then one will ultimately have business problems with that application. If you think I'm kidding, ask yourself why so much software can't pass basic accounting audit tests.
2. You example clearly shows that the "programmer" you refer to is completely unfamiliar with basic English syntax and sentence structure. The sentence (business rule) "employees must be 18 years of age or older" is perfectly clear to anyone understanding the "rules" of the English language. English has plenty examples of ambiguity, but this isn't one of them.

> b) All future programmers know **and agree upon** ALL the business
> rules. Exactly how you arrange to hire these perfect programmers, I
> do not know.

I'd hate to rely on perfection within a design of accounting software. Most of these types of applications should be designed with "imperfection" in mind.

> c) When there is a change ("The legal age for alcohol is now 21, so
> change the hiring rules') , you have a way to propagate it thru ALL the
> application programs. And can produce an audit to prove that you
> changed those front ends, even the ones that were written by another
> shop.

A rational initial design, and reasonable development management, can, and should, facilitate this "propagation" function.

> I have a three-part series at www.dbazine.com on this topic. My
> arguement is for doing it both places. Simple errors trapping in the
> front end can get a lot of the typos before they get to the backend.
> Check digits and other things are easy to verify in applications code
> and get an immediate correction. The human being is still the slowest
> thing in the process unless you can type one word per nanosecond :)

When the tools one has to work with requires this be done in both places then both places it shall be. :-)

Bill Received on Sat Dec 11 2004 - 14:30:16 CET