Just because one table has many columns does not mean it is not normalized.
The original message stated that there is all kinds of different information
about a contact from their first/last name to the high school they graduated
from. Given enough information about a person it would be easy to fill 75
columns of DIFFERNT data. Sure there may be a column to store phone
numbers... but that doesnt mean that in order to add another phone number
for a particular contact that you would insert a whole new row. Either a)
you decide not to keep more than one phone number per contact, and use an
update to change the phone number for that contact or b) create a phone
number table so you can create a one to many relationship (one row in the
contact table can have multiple rows in the phone number table).
In case b yes some information is taken out of the contact table and put
into another table, however that is just one column. For things like mothers
maden name and other unique and SINGLE data elements putting that data in
the contact table does not denormalize the table. The only situation in
which I can think to create a seperate table with this sort of information
is a) one contact may have many of column y or b) a majority of the contacts
dont have information for column y, so you create a seperate table for
column y to store the few rows you do have information for, so that your
contact table doesnt have a bunch of empty fields.
Hope this helps.
ryan
> 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
