>>Based on that, you *should be* ok to make it a clustered index. One thing I haven't seen mentioned here. A clustered index is really a physical storing of the data in index order. You can insert, but it could mean rewriting a large portion of data.
>>
>>>The ID is an Identity column. If a user creates an order it is (ID) automatically set to the next ID sequential number. If user does not save the newly created record, the "missed" number will never be inserted.
>
>Exactly - if the definition of the clustered index represents a level of randomness when inserting new rows, you potentially wind up with index fragmentation, which can really impact performance.
I understand what you are saying. But in the case that I am describing - PK column being an Identity and INT type - is there a downside to making the PK constraint clustered (vs. non-clustered)? I would leave it non-clustered but the execution plan clearly shows that the clustered index is used in much greater percentage.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
