Subject | Re: Design question |
---|---|
Author | csswa |
Post date | 2002-04-03T08:37:14Z |
You answered you own question: Yes!
Brush up on your understanding of entities and attributes. This is
the foundation of table design. Then make sure you know how to
normalize, and as part of this you need to understand intersection
tables (resolving many-to-many relationships, etc.).
Check the Group New User database for links to some basic SQL
resources or search online using keywords like: sql, normalization,
attributes, entities, design...
Regards,
Andrew Ferguson
Brush up on your understanding of entities and attributes. This is
the foundation of table design. Then make sure you know how to
normalize, and as part of this you need to understand intersection
tables (resolving many-to-many relationships, etc.).
Check the Group New User database for links to some basic SQL
resources or search online using keywords like: sql, normalization,
attributes, entities, design...
Regards,
Andrew Ferguson
--- In ib-support@y..., "Nico Callewaert" <ncw@t...> 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.
>
>
> Any good :-)))) ideas are welcome,
> Many thanks in advance,
>
> Nico Callewaert