How many columns are too many for a SQL Server 2005 table?

Question

I have a request to allow a dynamic table to have 1000 columns(randomly selected by my end users). This seems like a bad idea to me. It\'s a customizable table so it will

Answer 1

This smells like a bad design to me.

Things to consider:

Will most of those columns be contain NULL values?

Will many be named Property001, Property002, Property003, etc...?

If so, I recommend you rethink your data normalization.

Answer 2

That is too many. Any more than 50 columns wide and you are asking for trouble in performance, code maintenance, and troubleshooting when there are problems.

Answer 3

Did you think of viewing your final (1000 columns) table as the result of a crosstab query? Your original table would then have just a few columns but many thousand records.

Can you please elaborate on your problem? I think nobody really understand why you need these 1000 columns!

Answer 4

This will have huge performance and data issues. It probably needs to be normalized.

While SQl server will let you create a table that has more than 8060 bytes inteh row, it will NOT let you store more data than that in it. You could have data unexpectedly truncated (and worse not until several months later could this happen by which time fixing this monstrosity is both urgent and exptremely hard).

Querying this will also be a real problem. How would you know which of the 1000 columns to look for the data? Should every query ask for all 1000 columns in the where clause?

And the idea that this would be user customizable is scary indeed. Why would the user need a 1000 fields to customize? Most applications I've seen which give the user a chance to customize some fields set a small limit (usually less than 10). If there is that much they need to customize, then the application hasn't done a good job of defining what the customer actually needs.

Sometimes as a developer you just have to stand up and say no, this is a bad idea. This is one of those times.

As to what you shoud do instead (other than normalize), I think we would need more information to point you in the right direction.

And BTW, float is an inexact datatype and should not be used for fields where calculations are taking place unless you like incorrect results.