Excellent article - I'll be sharing this with my colleagues 🙂

One comment/question in the naming conventions area though (not to start a heated debate haha)... You state that using column names like ID, Name and Description are like poison. I'm curious why you've come to feel this is more confusing? I've actually come into the practice of doing exactly that because I'm thinking of the table definition as a type and a row as an object, which will most likely be represented in code at one point or another - in one way or another.

When I perform joins I just be sure to use aliases and ensure that the aliases are easy to understand (e.g. if I have a table "Transaction", "tx" would be an appropriate shortening, so "tx.ID" would become very readable). Though I think this is a bit of a moot point because, if you ask me, you should always use aliases when joining and aliases should always be easy to interpret to maintain good readability. Naturally this has the side-effect of bringing the "ID" column back into context.

When I have foreign key column, I like to name the column "{PrimaryKeyTableName}{PrimaryKeyColumnName}" (so, FK column "TransactionID" points to PK column "Transaction.ID" - and (though I'm still not a huge ORM fan yet...) when using an ORM this typically will end up exactly the same in code. When not using an ORM, I would definitely have a "Transaction" object with an "ID" property. "Transaction.TransactionID" just feels silly.

It just brings the references that the code/db make between entities/tables a little bit more in-sync in my opinion.

Thoughts?

Cheers,

Cyle