Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!wuarchive!sdd.hp.com!hplabs!pyramid!infmx!randall
From: randall@informix.com (Randall Rhea)
Newsgroups: comp.databases
Subject: Re: Balancing Normalization with Performance
Message-ID: <1990Nov27.030450.6251@informix.com>
Date: 27 Nov 90 03:04:50 GMT
References: <1092@cortex.med.jhu.edu> <1990Nov20.190315.13505@informix.com> <1990Nov21.185907.10061@inel.gov>
Sender: news@informix.com (Usenet News)
Distribution: usa
Organization: Informix Software, Inc.
Lines: 59

In article <1990Nov21.185907.10061@inel.gov> cdm@gem-hy.Berkeley.EDU (Dale Cook) writes:
>I think you are confusing design with implementation.  Database _designs_,
>IMHO, should always be normalized. 

What is "design" and what is "implementation"?  Where does one phase begin
and the other leave off?  I've never received a consistent answer to that
question from the various analysis methods I have come across.  Perhaps 
there is a reason for this; often, there is no clear dividing line between
them.   

>Remember that the goal of the 
>design is to understand your data and represent the data structure *as it
>logically exists* so that others can understand it as well

Absolutely correct!  What I mean by "over-normalization" is a database design
that does NOT represent the logical structure of the data: normalization 
that makes the data structure *more* difficult to understand. 

>|> 1. Any programs that need to look at the string would have to perform
>|> a sub-query.  In some report writer languages, this can be quite difficult.
>                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>So what?  That's why you get the big bucks, isn't it?

So what?  I'll tell you "so what" .... You won't get the job done, that's
"so what".  In the real world, we have to complete projects on time and
under budget.  I have spent countless hours tweaking report writers to
look at the zillions of tables that held the data I needed.  You may think
that "programmer inconvenience" is trivial, but programmer labor expenses 
are often far and away the most expensive piece of a project's budget. 

Maybe you guys who work for the government don't have to worry about
such things as "costs."  (heh heh heh, a tongue-in-cheek comment from
a frustrated taxpayer ...)

In the ideal world, where some database book authors live, we have perfect
computers, unlimited disk space, plenty of good programmers, unlimited time,
unlimited funds, and best of all ... a perfect RDBMS tool for the 
development of the system.  In the real world, we never have any of these
things.  I know that it's unfortunate when one must change the database
design (or "implementation") to make up for a bad programming tool. (or
bad programmers!) However, this is sometimes a painful reality.  Hey, you 
gotta get the $#@&# program written using the #&@!* lousy report writer.  
Sometimes, this means the database design must be simplified.  If it isn't,
you don't get the job done.  I know, you can always get another report
writer- provided you have the funds to do so.  If not, you're stuck.

My point is that your programming staff and your programming tools must
be taken into consideration when deciding how the database is to be
designed/implemented.  It's not as trivial as Dale thinks.

Overall, though, Dale makes a lot of valid points.  Database design/
implementation is not simple.  The postings on this net make this
painfully clear.

-- 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Randall Rhea                                          Informix Software, Inc. 
Senior Programmer/Analyst, MIS                    uunet!pyramid!infmx!randall