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

MS SQL Server has a limit of 1024 columns per table, so you're going to be running right on the edge of this. Using varchar(200) columns, you'll be able to go past the 8k byte per row limit, since SQL will store 8k on the data page, and then overflow the data outside of the page.

SQL 2008 added Sparse Columns for scenarios like this - where you'd have a lot of columns with null values in them.

Using Sparse Columns http://msdn.microsoft.com/en-us/library/cc280604.aspx

Answer 2

from SQL2005 documentation:

SQL Server 2005 can have up to two billion tables per database and 1,024 columns per table. (...) The maximum number of bytes per row is 8,060. This restriction is relaxed for tables with varchar, nvarchar, varbinary, or sql_variant columns that cause the total defined table width to exceed 8,060 bytes. The lengths of each one of these columns must still fall within the limit of 8,000 bytes, but their combined widths may exceed the 8,060 byte limit in a table.

what is the functionality of these columns? why not better split them into master table, properties (lookup tables) and values?

Answer 3

Whenever you feel the need to ask what limits the system has, you have a design problem.

If you were asking "How many characters can I fit into a varchar?" then you shouldn't be using varchars at all.

If you seriously want to know if 1000 columns is okay, then you desperately need to reorganize the data. (normalization)

Answer 4

I have to disagree with everyone here.....I know it sounds mad but using tables with hundreds of columns is the best thing I have ever done.

Yes many columns frequently have null values; Yes I could normalise it to just a few tables and transpose; Yes it is inefficient

However it is incredibly fast and easy to analyze column data in endless different ways

Wasteful and inelegant - you'll never build anything as useful!

Answer 5

Seems like an awful lot. I would first make sure that the data is normalized. That might be part of your problem. What type of purpose will this data serve? Is it for reports? Will the data change?

I would think a table that wide would be a nightmare performance and maintenance-wise.

Answer 6

As a rule: the wider the table the slower the performance. Many thin tables are preferable to one fat mess of a table.

If your table is that wide it's almost certainly a design issue. There's no real rule on how many is preferable, I've never really come across tables with more than 20 columns in the real world. Just group by relation. It's a RDBMS after all.