title: How many columns are too many for a SQL Server 2005 table?
body: <p>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 have a mixture of <code>varchar(200)</code> and <code>float</code> columns(float best matches the applications c++ double type).  This database is mostly an index for a legacy application and serves as a reporting repository. It's not the system of record.  The application has thousands of data points very few of which could be normalized out.</p>
  
  <p>Any ideas as to what the performance implications of this are?  Or an ideal table size to partition this down too?</p>
  
  <p>Since I don't know what fields out of 20k worth of choices the end users will pick normalizing the tables is not feasible.  I can separate this data out to several tables That I would have to dynamically manage (fields can be added or drooped.  The rows are then deleted and the system of record is re parsed to fill the table.)  My preference is to push back and normalize all 20k bits of data. But I don't see that happening.</p>