Another locking question

From this article by
Kalen...http://www.sqlmag.com/Articles/Index.cfm?ArticleID=26922...
she mentioned
"For INSERTS which are blocking, you might want to make sure that your
clustered index is NOT on a column that determines the order that the new
rows are arriving. For example, don't put your clustered index on OrderDate
or OrderNumber, which will always be increasing"
My quesion is why not ?I believe Kalen is just saying that if your inserts are causing blocking you
would not be helping the situation by having an index that uses these same
inserts as the logic to always through the data to the bottom of the last
leaf level of the table (clustered). I think that for inserts that are not
causing blocking it is quite acceptable to use a clustered index on a
sequential key (like an identity column).
Later in that same article Kalen talks about key locks, I've fixed quite a
few blocking issues by adding a clustered index to a table which then would
acquire these key locks. So you would have to test to ensure your inserts
are causing blocking.
HTH
--
Ray Higdon MCSE, MCDBA, CCNA
--
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:OivRkZZhDHA.484@.TK2MSFTNGP12.phx.gbl...
> From this article by
> Kalen...http://www.sqlmag.com/Articles/Index.cfm?ArticleID=26922...
> she mentioned
> "For INSERTS which are blocking, you might want to make sure that your
> clustered index is NOT on a column that determines the order that the new
> rows are arriving. For example, don't put your clustered index on
OrderDate
> or OrderNumber, which will always be increasing"
> My quesion is why not ?
>