Re: Database Design Question - any suggestion?
Date: Sat, 11 Dec 2004 11:46:43 -0500
Message-ID: <jskr82-qpl.ln1_at_pluto.downsfam.net>
Bill H wrote:
> 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.
This is one basis for choosing to formulate and maintain the authoritative statement of business rules in scalar data. If they can be resolved to the point where they can be expressed as operations on 2 or 3 operands, such as:
age,<,SystemConstant(maxage)
...where we have a function for maxage because of course we would *never* put a constant directly into code or meta-data.
>
>> 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.
It helps to think of propagation = development = installation, they are all the same thing. The meta-data, which is outside of both client and server, is used to update the server, including writing of constraints. Then the meta-data is supplied to the client (either at run-time, the slowest, or through complete code generation, the fastest, or by some in-between arrangement). This operation is fundamentally identical whether done by a programmer on his own box for brainstorming, or into the final production system for the customer many steps later.
>
>> 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. :-)
>
Or much better, when the tool *allows* the choice to do it in both places, happy are they who use the tool. I'm one of those who believes the db should be able to defend itself against all comers, never relying on a well-behaved application. However, it is a great convenience to the user if the client knows the biz rules also and can provide some automation and also save the user some headaches by preventing knowingly bad data from going back to the server.
-- Kenneth Downs <?php echo $sigblock ?>Received on Sat Dec 11 2004 - 17:46:43 CET