Primary key is bigint and identity, any reasons for preferring non clustered index over clustered index

I've a table which is defined like this

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]

Apart from above PK_MyTable NONCLUSTERED index, I've few other NONCLUSTERED indexes over SomeTable2Id and SomeTable3Id

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?

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.

EDIT: Consider a case where MyTable is mapping two other tables SomeTable2 and SomeTable3 and instead of having composite key, we have this MyTableId So most of the time my queries have either SomeTable2Id or SomeTable3Id 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 MyTableId or two nonclustered indices over SomeTable2Id and SomeTable3Id are suffi开发者_如何学JAVAcient?

No, you definitely should have a clustered index there. That Identity field is an ideal cluster key as well.

Here are some good articles from Kim Tripp regarding clustered indexes:

Clustered Index Debate

Clustered Index Debate Continues

Here is a whitepaper from MS about this topic as well.

I think you definitely should have MyTableId as your the key in a clustered index without further information about how the table is actually used.

Remember, you are choosing between the table being a clustered index or a heap. A clustered index is not an index on the table, but identifies that the table is stored in a B-tree based on the clustered index key.

On both kinds of tables, non-clustered indexes can also be used.

For read performance (particularly on wider tables), the non-clustered indexes (potentially with included columns) are going to be where you are looking for gains.