*snip*
>Conclusion: Every table in SQL Server should have a clustered index. In the absence of knowing which key to choose, you then go with the PK.
>

John,
I disagree with this entirely. IMO, clustered indexes are created with a purpose. If no purpose exists then creating one is superfluous.

Clustered indexes physically order the table. The reason for them IMO, is to create blocks of data. Returning the least amount of pages of data is key to performance. If the data you are returning is ordered so tht the block(s) you need are located on a single page or consecutive pages, BINGO! Your job is done.

However, if your queries are going to be drawing data from all over the table, a clustered index is not necessary. And in fact, if you base a clustered index on an auto incrementing, surrogate key, in essence you get the same ordering as if you had no clustered index at all. The table is still ordered in the order in which the row was added to the table. What benefit is there? An index scan of a clustered index based on this is no better than a table scan (it's the same).

No, my conclusion is a bit different.

Design your clustered indexes around your queries. If this is not possible for whatever reason (e.g. CRUD operation performance), don't use them.