Subject | Re: [ib-support] Design question |
---|---|
Author | Svein Erling Tysvær |
Post date | 2002-04-03T09:23:30Z |
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
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.