Reasons not to have a clustered index in SQL Server 2005

Question

I\'ve inherited some database creation scripts for a SQL SERVER 2005 database.

One thing I\'ve noticed is that all primary keys are created as NON CLUSTERED

Answer 1

Please read my answer under "No direct access to data row in clustered table - why?", first. Specifically item [2] Caveat.

The people who created the "database" are cretins. They had:

• a bunch of unnormalised spreadhseets, not normalised relational tables
• the PKs are all IDENTITY columns (the spreadsheets are linked to each other; they have to be navigated one-by-one-by-one); there is no relational access or relational power across the database
• they had PRIMARY KEY, which produce UNIQUE CLUSTERED
• they found that that prevented concurrency
• they removed the CI and made them all NCIs
• they were too lazy to finish the reversal; to nominate an alternate (current NCI) to become the new CI, for each table
• the IDENTITY column remains the Primary Key (it isn't really, but it is in this hamfisted implementation)

For such collections of spreadsheets masquerading as databases, it is becoming more and more common to avoid CIs altogether, and just have NCIs plus the Heap. Obviously they get none of the power or benefits of the CI, but hell, they get none of the power or benefit of Relational databases, so who cares that they get none of the power of CIs (which were designed for Relational databases, which theirs is not). The way they look at it, they have to "refactor" the darn thing every so often anyway, so why bother. Relational databases do not need "refactoring".

If you need to discuss this response further, please post the CREATE TABLE/INDEX DDL; otherwise it is a time-wasting academic argument.