I had a conversation, recently, with a number of colleagues, all seasoned professionals, with differing opinions on naming conventions for primary keys in tables. Many held the position that a primary key should only be named Id. Others felt the primary key should be named using the table name followed by Id.
The persons holding to the Id position felt that having the prefix of the table name was redundant. If the table name was Bus, then having the key be BusId was redundant. You knew it was the key of the bus table because it was contained in the Bus table.
Those holding the position of the key being named BusId were looking at the problem from a perspective of consistency. The property was named BusId in the database, regardless of where it was found.
There were good reasons on both sides of the argument. If the primary key of every table is Id, it makes it possible to write software connected to the database in a generic fashion. There is no difference from one table to another when referencing the primary key. They are all, Id, and a single code module works if you use generics.
The database group had come from the experience of databases being defined using Id as the primary key. However, there was no referential integrity implemented in the database. When no database diagram was available, the intention of all the relationships was easily derived by humans, but much more difficult for computer software reverse engineering the database structure.
Should the simplicity of writing data access code determine the database column naming convention? Should reverse engineering drive naming conventions?
Share your position, and any reasoning you find helpful, by leaving a comment.
Cheers,
Ben