I disagree, you should separate the data to a CUST_DELIV Table.
Each customer could have more than 1 delivery location.

You should think of your tables as single entities.
Your Customer table should ONLY have information that pertains to a single
Customer (i.e. what makes up a Customer).

Just my 20000 * 10^-6 cents.

-----Original Message-----
From: Svein Erling Tysvar
[mailto:svein.erling.tysvaer@...]
Sent: Wednesday, April 03, 2002 1:24 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] Design question


Well Nico, you're the one who have to decide whether the suggestions are
good or not!

I'd recommend you to be conservative about adding fields - that is, don't
implement every idea from every user. Try to get user A talk to user B so
that the three of you can agree in what ideas are worth implementing. It is
not uncommon for users to come up with what they think is a good idea only
to find out a week later that they had forgotten to take something into
consideration and really wanted some different information.

As for splitting a table, there is normally no need for doing this only
because of the number of fields in a table. Rather, think about the data.
Repeating groups etc. are of course worth splitting into separate tables
(normalisation theory) and you may consider separate tables for fields
irrelevant for most records. In your example, I wouldn't bother to have a
separate CUST_DELIV table if the eight fields typically were filled for
most customers - unless you wanted to record some history so that you knew
the delivery information at any given time (companies may move or have
several delivery addresses).

But I must admit that 50 fields sounds a lot for a customer table - does
all fields really contain different information?

HTH,
Set

>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.

To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/