From: andersen@reality (Robert Andersen)
Subject: Re: Data Base design pet peeve
Organization: Encompass
Date: Mon, 28 Sep 1992 15:28:31 GMT

In article <1992Sep28.001827.1038@RedBrick.COM> jfr@RedBrick.COM () writes:
>  
> This notion of "planning for the future" as a justification for choosing
> one type of data representation (possibly the wrong one) over another
> always elude me.  If the guy KNOWS his database isn't going to grow
> over 99 customers, maybe he should use a ONE BYTE integer instead of
> a TWO BYTE one, hey?  Wouldn't this save even more space?  And if he
> has made a mistake and needs more than 32767 (or 64K if you support
> unsigned ints), then shouldn't he use a FOUR BYTE integer from the
> start?  Why is TWO BYTEs inherently better than any other choice the
> user might decide to make?  The real problem here is that most databases
> are REALLY CRUDDY at rapid adaptation to changing database requirements.

  I agree with you that most databases don't support rapid changes for DB  
requirements.  But the real issue isn't the DB change alone.  Even if you had a  
large database you could come up with an application that would allow you to  
map your current schema to a modified schema, the company I work for has just  
such a utility, even though it is a little limited it helps greatly.  The  
problem is that the 3GLs/4GLs that interface to your DB would have to be  
changed.   If you had over 50 tables that had the same primary key, it would  
take a lot longer to change the 3GLs/4GLs then it would to make the DB change,  
assuming you had a utility and did not have to do it by hand.

> .....  
> The point of the above is that, IMHO, you should do database and data
> design based on what you need today and for the foreseeable future and
> based on the "most appropriate" representation for the data.  And the
> system and tools you use should make it simple to adapt to the future. 
> If they don't, you may be using the wrong system or tools.

  What time frame is your foreseeable future?  Depending on the requirements ,  
you might foresee having thousands of customers in the next five years, but  
only have hundreds within the first 2 years.

> BTW, as another point, the argument is made that using an integer is
> "faster" than using a character string.  But what about the effort
> involved in converting integers to character strings for external
> representation?  So maybe searching on a string is slightly longer
> (although I don't necessarily agree with this thesis and it certainly
> depends on the processor) but converting to and from internal format
> will be much longer for the integer than for the string.  The main point
> is that you should be MUCH less concerned with the space/time tradeoffs
> at least in the early stages of design, than you are in what is RIGHT.
> 

  I have a major problem with your last sentence.  You might not want to be  
overly concerned with space/performance in the early design stage, but usually  
companies who do that don't have the time to go back and tweak it for  
performance because they are rushing to get it completed.  Why not do all the  
analysis up front. Besides what is RIGHT, is it right to come up with a design  
that takes up a lot of space/time or is it right to do a boat load of analysis  
up front so that you app is quick and does not chew up disk space.  Last point,  
even though you do have to convert an integer to character representation to  
view it, that conversion should be done in the application not the DB.  You  
want to make your DB as efficient with disk space and performance as you can,  
because you usally have more than one app running against it.  Of course if you  
only have one app running against a DB then space/time concerns are usally not  
that important.


--
Robert John Andersen           
(919) 380-6523 (v,w)
andersen%reality@glv.com - NeXT mail!

Outside of a dog, a book is man's best friend.
Inside of a dog it's too dark to read.