Good article. I too am amazed by how many people are willing to forgo primary keys on small tables. Data integrity always preceeds performance (esp such a slight gain). Also, without this PK, you can't create the appropriate foreign keys, which is also a data integrity issue. My experience is if you don't make the relation, you end up with orphans.

One technical point: if you create a table using TSQL in Query Analyzer, the PRIMARY KEY constraint is always clustered unless a clustered index already exists or you specify NONCLUSTERED.

As far as no primary keys on temp tables, this position also has little validity. We key our temp tables, and have generated PK violations that would have gone unknown to us and produced erroneous results without them.

Tables having a clustered index, however, is less certain. I recently had the experience of seeing a significant jump in performance in some temp tables by adding NONCLUSTERED to the create command. The tables were still keyed, but the absence of a CLUSTERED index helped tremendously.

I don't recommend as a "damn good start" adding and clustering an identity column. There would almost always be a better choice for a clustered column, and these bad habits might be hard to break.

Still, I will refer to this article anytime someone tells me I might not want to key my small tables.