title: Clustered vs covering index
body: <p>Consider the following table in SQL Server 2008:</p>
  
  <pre><code>LanguageCode  varchar(10)
  Language      nvarchar(50)
  </code></pre>
  
  <p>LanguageCode participates in relationships, so I cannot create a primary key index that includes both columns (LanguageCode, Language).</p>
  
  <p>If I put a primary clustered key on LanguageCode, of course I can't include Language in the index (covering index). This means that I will have to create a second index for Language, or run the risk of having duplicates in it (plus force a table scan to retrieve its value).</p>
  
  <p>Further, MS's documentation (as well as experts on the subject) indicate that a table should <strong>ideally</strong> have a clustered index.</p>
  
  <p>In this case, a non-clustered covering index (LanguageCode, Language) would not only ensure that Language is unique, but would avoid the table scan. However, there would be no "ideal" clustered index.</p>
  
  <p>Is this one of those cases where having no clustered index is in fact ideal?</p>
  
  <p><strong>Edit based on feedback:</strong></p>
  
  <p>The only query I wish to run is:</p>
  
  <pre><code>SELECT Language, LanguageCode FROM Languages where Language="EN"
  </code></pre>