title: Is there a reason for a Primary Key column that would never be used?
body: <p>I have a routine that will be creating individual tables (Sql Server 2008) to store the results of reports generated by my application (Asp.net 3.5). Each report will need its own table, as the columns for the table would vary based on the report settings. A table will contain somewhere between 10-5,000 rows, rarely more than 10,000.</p>
  
  <p>The following usage rules will apply:</p>
  
  <ul>
  <li>Once stored, the data will never be updated. </li>
  <li>Whenever results for the table are accessed, all data will be retrieved. </li>
  <li>No other table will need to perform a join with this table.</li>
  </ul>
  
  <p>Knowing this, is there any reason to create a PK index column on the table? Will doing so aid the performance of retrieving the data in any way, and if it would, would this outweigh the extra load of updating the index when inserting data (I know that 10K records is a relatively small amount, but this solution needs to be able to scale).</p>
  
  <p><strong>Update</strong>: Here are some more details on the data being processed, which goes into the current design decision of one table per report:</p>
  
  <ul>
  <li>Tables will record a set of numeric values (set at runtime based on the report settings) that correspond to a different set of reference varchar values (also set at runtime based on the report settings).</li>
  <li>Whenever data is retrieved, it some post-processing on the server will be required before the output can be displayed to the user (thus I will always be retrieving all values).</li>
  </ul>
  
  <p>I would also be suspicious of someone claiming that they had to create a new table for each time the report was run. However, given that different columns (both in number, name and datatype) could conceivably be needed for every time the report was run, I don't see a great alternative. </p>
  
  <p>The only other thing I can think of is to have an ID column (identifying the ReportVersionID, corresponding to another table), ReferenceValues column (varchar field, containing all Reference values, in a specified order, separated by some delimiter) and NumericValues column (same as ReferenceValues, but for the numbers), and then when I retrieve the results, put everything into specialized objects in the system, separating the values based on the defined delimiter). Does this seem preferable?</p>