On 3 Apr 2002 at 7:55, Nico Callewaert wrote:

> Hi all,
>
> I'm wondering already long time what is the best aproach. Most of
> the
> time a table starts with a limited number of fields. Then user A
> wants to have additional info, then user B pops up with some other
> fields, and if you always add those fields in the same table , after a
> few months it looks like a mess. Sometimes you start with 20 fields
> and before you know, you have a table with 60 fields. I don't feel
> so good about this. For example I have a customer table, with
> already 50 fields. Everything is in one table. Now the question is,
> should I split up fields in seperated tables ? For example, in my
> CUST table, there are 8 fields to hold delivery information, should I
> split up that information in a CUST_DELIV table ? I just doubt about
> those things, because I like "clean" work.
>

It's perfectly normal, for databases to "grow" after the application has been in
production for a while, because users may decide to do more then the initially
thought possible. However when you add new fields, you need to re-visit the
normalisation of the data, to see whether a new data item should be added to
existing tables, or whether that information would be better on it's own as a separate
table. However splitting information off just because a table has grown, is simply
moving the problem of a large field count on tables, to a large table count on a
database.

If your not sure of the process of normalization, then get a good SQL book, although
it doesn't mention Firebird (or Interbase for that matter) a good book is Instant SQL
programming by Joe Celko (ISBN 1-874416-50-8). This book has most of a chapter
on normalization.


PaulPaul Schmidt
Tricat Technologies
paul@...
www.tricattechnologies.com