Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!pmafire!mica.inel.gov!gem-hy!cdm
From: cdm@gem-hy.Berkeley.EDU (Dale Cook)
Newsgroups: comp.databases
Subject: Re: Balancing Normalization with Performance
Message-ID: <1990Nov26.204658.9692@inel.gov>
Date: 26 Nov 90 20:46:58 GMT
References: <1092@cortex.med.jhu.edu> <1990Nov20.190315.13505@informix.com> <1990Nov21.185907.10061@inel.gov> <33418@netnews.upenn.edu>
Sender: news@inel.gov
Reply-To: cdm@gem-hy.Berkeley.EDU (Dale Cook)
Distribution: usa
Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho
Lines: 79

In article <33418@netnews.upenn.edu>, aaron@grad2.cis.upenn.edu (Aaron
Watters) writes:
|> In article <1990Nov21.185907.10061@inel.gov> cdm@gem-hy.Berkeley.EDU
(Dale Cook) writes:
|> >Programmer 
|> >convenience is not a legitimate tradeoff, or at least pretty damn low
|> >on the list.  Balance query time against update time.  Consider data
|> >volatility when considering storing summary information.  Try to
look ahead in
|> >time.  Will the data be used by other applications?  Will it change?
|> >My point is that denormalization should not be undertaken lightly.  You
|> >should understand the consequences of it, both near and long term.
|> >The benefits to the entire system should be clearly identified.
|> >
|> >--- Dale Cook   cdm@inel.gov
|> 
|> On the contrary, programmer convenience is directly related
|> to the cost of maintaining and extending the database.  In
|> fact you could argue that the entire subject of database systems
|> is motivated by questions of programmer convenience.

The cost of maintaining and extending a database is far more closely
related to the design of the data than to programmer convenience.  True,
databases have many features which facilitate programmer productivity
(concurrency, locking, etc), but this does not mean that the database
is there solely for programmer convenience.

|>  (Why don't
|> we just write everthing from scratch directly on top of the file
|> system, anyway?)  Further, as database systems get more elaborate

Better yet, why normalize at all?  Just make one big flat file... :-)

|> and technical the distinction between an end-user and a programmer
|> blurs rapidly.

Wrong.  The *need* for a programmer diminishes.  Programmers are 
seldom end users (with the exception of tools used in support of
programming), but more and more end users are acquiring programming
skills.  
|> 
|> I would draw the alternate conclusion that
|> database systems should provide facilities that reduce the 
|> hassles of working with a highly normalized databases -- such
|> as good support for complex views among other things.  It is
|> not clear this is always done.			-aaron

I used the term "programmer convenience" to mean just that - _programmer_
convenience, not end user convenience.  My earlier posting on this
subject stated that end user convenience _is_ a legitimate reason for
denormalization.  Perhaps more to the point: is the primary use of the
database geared towards adhoc usage, or towards "batch" usage, where 
canned programs are the norm?  In an adhoc environment, the programmer
tends to become part of an information center, where end-user requests
are satisfied.  In this mode, the programmer becomes an extension of
the end user, and convenience may become a legitimate concern.
In a "batch" environment, where you tend to have the
classical payroll, personnel, accounting, etc., systems, programmers
are creating less customized reports for a wide distribution.  It is
in this environment where programmer convenience is low on the list.

I would agree with your alternate conclusion.  But I stand by my
contention that programmer snivelling about complicated queries is 
not a good reason, in and of itself, to denormalize.  There are more
important factors.

--- Dale Cook    cdm@inel.gov
========== long legal disclaimer follows, press n to skip ===========
^L
Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.