Good article. (Was that an echo?) It is always worth reading up on how other people do, let's call it "non-standardized" things, such as naming and coding conventions. Eventually, they become widespread standards, or so one can only hope.

A quick thought or two: for indexes and the like, instead of tagging them with a number we put the column actually indexed at the end (such as PK_Table_ColumnName). For compound indexes, either we do multiple columns, a brief description, or (if too long) an arbitrary number (1, 2, etc.) All this makes it easier to get a list of indexes for a table and see what's covered and what's not.

I'll toss in our foreign key naming conventions: FK_<child table constraint is "owned" by>_<parent table constraint references>. Having consistent names on the "hidden" database objects (indexes, defaults, constraints, triggers) has made management a LOT easier the few times it's really mattered.

Steve, just from idle curiosity, and with no intent to provoke lengthy debate on points of religious dogma, are there an particular reasons why do you avoid underscores and all-upper case words? We mix and match in what I like to think of as a judicious fashion. When reading code or reports, quick visual identification of disparate objects can be very useful.

Philip