Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!ucbvax!mtxinu!sybase!ohday!tim
From: tim@ohday.sybase.com (Tim Wood)
Newsgroups: comp.databases
Subject: Re: Balancing Normalization with Performance
Message-ID: <11943@sybase.sybase.com>
Date: 30 Nov 90 19:17:24 GMT
References: <1092@cortex.med.jhu.edu> <1990Nov20.190315.13505@informix.com> <1990Nov21.185907.10061@inel.gov> <33418@netnews.upenn.edu>
Sender: news@Sybase.COM
Distribution: usa
Organization: Sybase, Inc.
Lines: 63

In article <33418@netnews.upenn.edu> aaron@grad1.cis.upenn.edu (Aaron Watters) writes:
>In article <1990Nov21.185907.10061@inel.gov> cdm@gem-hy.Berkeley.EDU (Dale Cook) writes:
>
>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.  
>(Why don't
>we just write everthing from scratch directly on top of the file
>system, anyway?)  

I don't agree.  For large multi-user databases, the emphasis should be
on making life easy for the end-users at the remote terminals spread 
throughout the service area, eg. bank tellers.  Making the teller's 
job of using the computer easy means that transactions will be generated
faster during busy periods and the business will be more productive.  

I'd say programmer convenience is a subordinate priority to end-user
convenience, because there are many more users than programmers of
large databases.  Also, programmer convenience will be determined more
by the power of the application development tools than by database
features.  After all, 4GL applications could manage that flat-file 
database, though data integrity would be very exposed; users could
still be spared the resulting ugliness :-).

Database features should be more oriented toward preserving data integrity.
Of course, there are easy and hard ways to do that.  For a programmer,
preserving referential integrity via a trigger is the hard way, via a
declaration is the easy way.  However, the choice could be hidden in a
application tool which either generated a template referential
integrity trigger and substituted specific object names, or simply
generated the referential declaration.  I feel the declarative approach
is better, because it is simpler at any level.  This makes it the
product vendor's responsibility to handle the complexity of building
declarative r.i. into the product internals.  Complexity doesn't go
away, it is just moved around.  The idea is to leverage it.

>Further, as database systems get more elaborate
>and technical the distinction between an end-user and a programmer
>blurs rapidly.

Not if it's designed properly.  As a system gets more features, it's 
going to be harder to use at some level because of the need to select
among the features.  But the system should allow hiding of that complexity
at appropriate levels so that one only need know a few simple things
to do something simple.  The larger the learning investment a user needs
to make in a system before doing the first unit of useful work, the 
less optimal is that system's design.

>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

Agreed (funny, since I disagreed with your premises :-).  
That's why adding complexity is costly--to do it right, you have
to concurrently create schemes for hiding it.  
-TW

Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608	  415-596-3500
tim@sybase.com          {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim
Dis claim er dat claim, what's da difference?  I'm da one doin da tawkin' hea.


Brought to you by Super Global Mega Corp .com