title: Clustered Index on date
body: <p>I'm redesigning a database for a project, since the current version does not match the reality of it's usage anymore and is causing serious problems.</p>
  
  <p>Several of the main tables consist of this structure:</p>
  
  <ul>
  <li>Object Identifier (FK, 4 byte int)</li>
  <li>Datetime of record (can be duplicate for different objects)</li>
  <li>Value (float)</li>
  </ul>
  
  <p>From other questions (i.e. <a href="https://stackoverflow.com/questions/3202086/composite-clustered-index-in-sql-server">Composite Clustered Index in SQL Server</a>) i gather that clustered indexes shouldn't be used on composite keys, and preferably smaller datatypes.</p>
  
  <p>The data in this table (several millions records and growing by 10k a day) only ever gets inserted or queried based on the datetime field (get min/max value or all values for object in date range), updates and deletes almost never happen and only outside hours where querying happens.
  The order of inserts is usually with increasing datetimes, but slight differences are observed and sometimes larger backlogs need to be inserted. 
  The order of a potential ID field would correctly match the datetime growth of a single object, but won't in general for all records.</p>
  
  <p>My question is: I see several different ways to do Keys/Indexes on this kind of table, but what approach for the keys would work best in these cases?</p>