how many field we keep in table

Question

How many field is possible in one table,

Shall i maintain 150 field in one table is good way ,

OR

Maintain relation ship with other tables,

Thanks Bharanikumar

Answer 1

http://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html

Answer 2

In the vast majority of cases having 150 columns in a single table is symptomatic of a badly denormalized database.

You might want to read this and re-evaluate your db design.

To put it in your terms, go with "maintain relationship with other tables"

Answer 3

If you have a business need to have 150 columns, then it's a "good way". I've never seen such a business need, but that doesn't mean one doesn't exist. I have seen very wide tables used in olap type cases, so if that's what you're doing, there's a good chance that you're on the right track. If you're using this table for more otap functionality, then you're probably going down the wrong road. Perhaps if you provided a bit more info about what you're trying to accomplish, we could provide some advice (instead of "do that" or "do it a different way").

Answer 4

150 bit type fields might be OK, but you also have to consider the maximum length of the record your database will allow you to store. With varchar fields, most databases will let you create a table that would in theory violate the max if all the fields were filled to their max length. However, it won't let you actually add records which are too long,. This is the kind of trap that can go along fine for years until someone puts just one character too many into a potential insert and then blow up and it takes a long time generally to find an fix such a problem. It is best to avoid ever designing a table where the total legnth of the columns is bigger than the length of the maximum record bytes.

Less wide tables can also tend to be faster to query.

Additonally 150 columns is usually a sign that you really need to look at the design and see if a related table would be better. For instance if you have phone1, phone2, phone3, then you need a related phone table.

If you genuiniely need all 150 columns, consider which are likely to be queried together most often. Put those inteh parent table. Then add the less often queried (or columns related only toa particular function) to the related table. There is no reason not to have a 1-1 relationship between tables, just use the id from the parante table sa the PK inthe child table as well as the FK to the parent table.