Well with tables not normalized you will more then likely at some point in
get redundant data at some point. For instance I enter Joe smith with phone
of 123-123-1222 then Joe Smith buys a new home keeps the other home and now
has two active phone number with on table you would have to reenter
information already in the database on Joe Smith unless you keep adding more
columns to accommodate each new phone number(this would be very poor
database design). Its basic normalizing of tables that will keep this from
happening. Its is very dependent on the nature of the data on whether you
need to break that table up or not. I would find it very hard to believe
that all the information needed for customer/contact data
from there name all the way to where they went to high school could be
stored in one table logically or more importantly efficiently.
-----Original Message-----
From: ryc [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 11:58 AM
To: 'Richard Reina'; [EMAIL PROTECTED]
Subject: Re: Hom many columns is too many?
I dont think the problem was redudant data. He is talking about 75 distinct
fields that no other table contains and ALL data is related to the contact.
It makes sence that a table with more columns would have a higher overhead
when parsing the queries, but but other than that I dont _think_ there
should be a major problem having a table with that many columns. However 75
does seem like it is a very obscene amount for one table, so you may want to
consider creating one table that stores the contacts primary information
(name, address, phone #, business name, ect... ) that is imparative to
working with the contact, and then have another table that contains more
detailed background information. This way if you need the information from
the second table you can left join it, and if you dont need it you dont have
to. Or another scheme is only insert detailed data for the contacts you have
that information on, and leave the rest blank (in this case you wont be able
to use left join because if the column you join on is missing from the
details table the query will return empty, even though the contact is in the
primary table). Either way there are trade offs, decide what is best based
on how much detail information you have from the contacts, and how you want
to lay out your code.
Hope that helps,
ryan
> With relational database design you can more then likely break that 75
> column table down into many different tables. Look up information on
NORMAL
> FORM this will help you design an effective database. Usually from what
I
> know and have been taught 3rd normal form is as low a level as you want to
> go. But this also depends on things such as how large your db will be.
> Sometimes redundant data is not always a bad think. In that case a lower
> normal form would be fine too. Its an art not a science:)
>
> RH
>
> -----Original Message-----
> From: Richard Reina [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 1:26 PM
> To: [EMAIL PROTECTED]
> Subject: Hom many columns is too many?
>
>
> I am designing an in house database app. for sales/contact management.
> We've identified out about 75 things to know about a customer/contact
> from there name all the way to where they went to highschool. Should
> all these attributes be in one table since they all describe the contact
> or should they be broken up into seperate tables like education,
> professional backround, business backtound special interests?
>
> ---------------------------------------------------------------------
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail
> <[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>
> ---------------------------------------------------------------------
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail <[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail
<[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
