title: Primary key is bigint and identity, any reasons for preferring non clustered index over clustered index
body: <p>I've a table which is defined like this</p>
  
  <pre><code>CREATE TABLE [dbo].[MyTable](
      [MyTableId] [bigint] IDENTITY(1,1) NOT NULL,
      [SomeTable2Id] [bigint] NOT NULL,
      [SomeTable3Id] [bigint] NOT NULL,
      [SomeData] [smallint] NOT NULL,
   CONSTRAINT [PK_MyTable] PRIMARY KEY NONCLUSTERED 
  (
      [MyTableId] ASC
  )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 80) ON [PRIMARY]
  ) ON [PRIMARY]
  </code></pre>
  
  <p>Apart from above PK_MyTable NONCLUSTERED index, I've few other NONCLUSTERED indexes over SomeTable2Id and SomeTable3Id</p>
  
  <p>I think creating CLUSTERED index above makes more sense but I'm wondering is there any good justification for NOT creating a CLUSTERED index and instead creating NONCLUSTERED?</p>
  
  <p>PS There are lot of questions asked over these topics but couldn't find relevant one (in top 20 list). If this has been asked, please redirect me to the related question post. </p>
  
  <p>EDIT: Consider a case where <code>MyTable</code> is mapping two other tables <code>SomeTable2</code> and <code>SomeTable3</code> and instead of having composite key, we have this <code>MyTableId</code> So most of the time my queries have either <code>SomeTable2Id</code> or <code>SomeTable3Id</code> and request to get other id. So in this light of usage of this table, do we really need to bother with creation of a clustered index over <code>MyTableId</code> or two nonclustered indices over <code>SomeTable2Id</code> and <code>SomeTable3Id</code> are sufficient?</p>