Re: Normalize until neat, Automate until Complete

Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:<o5ve72-r03.ln1_at_pluto.downsfam.net>... <snip>
> The fact that so many people in the real world are willing to denormalize
> suggests that the RDM in itself is not providing a complete set of guiding
> principles for real-world database operations.

no. vendors aren't interested in doing the work to provide a physical implementation which is normalization neutral.

 When people "denormalize
> for performance", and I don't mean amateurs here, they are reaching for
> something.

they are practicing faith based science. they assume that retrieving a single row from a monster flat table is cheaper than joining two or more tables. such folk routinely only measure "fetch" time. they ignore both the set operation and the added code execution to ensure logical integrity (or don't bother, and perpetually chase "strange" data errors.)

Just as perturbations in a planet's orbit can lead scientists
> to suspect and discover other planets, perhaps theoreticians can look at
> the practioners' efforts and realize that there must be more to the story.

see above. it's poor physical implementation. on DB2/390, the data is
stored in VSAM. guess what's faster at unadorned retrieval: COBOL/VSAM
or DB2???

>
> I would suggest a better slogan would be "Normalize until Neat, Automate
> until Complete," which actually gives some guidance to the denormalization
> process. The idea is that user-entered or imported data should be
> normalized for standard reason, nothing new there. The process of
> automation requires a normalized database as a starting point, so that the
> generated columns are built upon a valid base.
>
> I have a simple question for those who oppose automation on the grounds that
> it denormalizes. If normalization is intended to ensure correctness, and
> your system disallows writes to automated columns, have you not preserved
> correctness while also improving the lot of your users? If so, isn't that
> what it's all about?

triggers, which is how this is done, have a cost. declarative RI is always
cheaper (that's according to my faith, of course.)
>
> If we separate theory from implementation for a moment, which means that we
> lay aside performance concerns, then the only motivation for automation is
> to make the database more complete.

more complete than what?? how is 3NF/BCNF less than complete? in a later msg. you discuss calculated columns, etc. i've never seen these as germane to the normalization question, per se. this is an empirical
optimization (in the calculus sense of finding the minimum) between calc-ing and storing vs. calc-ing at retrieval. you pays your money, you takes your choice.

 If it can be made more complete
> without threatening correctness, is not this an a priori Good Thing?
Received on Thu Nov 25 2004 - 02:51:00 CET