Database design - primary key naming conventions

Question

I am interested to know what people think about (AND WHY) the following 3 different conventions for naming database table primary keys in MySQL?

-Example 1-

Table name: User,
Primary key column name: user_id

-Example 2-

Table name: User,
Primary key column name: id

-Example 3-

Table name: User,
Primary key column name: pk_user_id

Just want to hear ideas and perhaps learn something in the process :)

Thanks.

Answer 1

I would go with option 2. To me, "id" itself seems sufficient enough. Since the table is User so the column "id" within "user" indicates that it is the identification criteria for User.

However, i must add that naming conventions are all about consistency. There is usually no right / wrong as long as there is a consistent pattern and it is applied across the application, thats probably the more important factor in how effective the naming conventions will be and how far they go towards making the application easier to understand and hence maintain.

Answer 2

I tend to go with the first option, user_id.

If you go with id, you usually end up with a need to alias excessively in your queries. If you go with more_complicated_id, then you either must abbreviate, or you run out of room, and you get tired of typing such long column names.

2 cents.

Answer 3

OK so forget example 3 - it's just plain silly, so it's between 1 and 2.

the id for PK school of thought (2)

drop table if exists customer;
create table customer
(
id int unsigned not null auto_increment primary key, -- my names are id, cid, cusid, custid ????
name varchar(255) not null
)engine=innodb;

insert into customer (name) values ('cust1'),('cust2');

drop table if exists orders;

create table orders
(
id int unsigned not null auto_increment primary key, -- my names are id, oid, ordid
cid int unsigned not null -- hmmm what shall i call this ?
)engine=innodb;

insert into orders (cid) values (1),(2),(1),(1),(2);

-- so if i do a simple give me all of the customer orders query we get the following output

select
 c.id,
 o.id
from
 customer c
inner join orders o on c.id = o.cid;

id  id1 -- big fan of column names like id1, id2, id3 : they are sooo descriptive
==  ===
1     1
2     2
1     3
1     4
2     5

-- so now i have to alias my columns like so:

select
 c.id as cid, -- shall i call it cid or custid, customer_id whatever ??
 o.id as oid
from
 customer c
inner join orders o on c.id = o.cid; -- cid here but id in customer - where is my consistency ?

cid oid 
==  ===
1     1
2     2
1     3
1     4
2     5

the tablename_id prefix for PK/FK name school of thought (1)

(feel free to use an abbreviated form of tablename i.e cust_id instead of customer_id)

drop table if exists customer;
create table customer
(
cust_id int unsigned not null auto_increment primary key, -- pk
name varchar(255) not null
)engine=innodb;

insert into customer (name) values ('cust1'),('cust2');

drop table if exists orders;
create table orders
(
order_id int unsigned not null auto_increment primary key,
cust_id int unsigned not null 
)engine=innodb;

insert into orders (cust_id) values (1),(2),(1),(1),(2);

select
 c.cust_id,
 o.order_id
from
 customer c
inner join orders o on c.cust_id = o.cust_id; -- ahhhh, cust_id is cust_id is cust_id :)

cust_id order_id
======= ========
1           1
2           2
1           3
1           4
2           5

so you see the tablename_ prefix or abbreviated tablename_prefix method is ofc the most consistent and easily the best convention.

Answer 4

I've always appreciated Justinsomnia's take on database naming conventions. Give it a read: http://justinsomnia.org/2003/04/essential-database-naming-conventions-and-style/

Answer 5

I agree with @InSane and like just Id. And here's why:

If you have a table called User, and a column dealing with the user's name, do you call it UserName or just Name? The "User" seems redundant. If you have a table called Customer, and a column called Address, do you call the column CustomerAddress?

Though I have also seen where you would use UserId, and then if you have a table with a foreign key to User, the column would also be UserId. This allows for the consistency in naming, but IMO, doesn't buy you that much.

Answer 6

ID is the worst PK name you can have in my opinion. TablenameID works much better for reporting so you don't have to alias a bunch of columns named the same thing when doing complex reporting queries.

It is my personal belief that columns should only be named the same thing if they mean the same thing. The customer ID does not mean the same thing as the orderid and thus they should conceptually have different names. WHen you have many joins and a complex data structure, it is easier to maintain as well when the pk and fk have the same name. It is harder to spot an error in a join when you have ID columns. For instance suppose you joined to four tables all of which have an ID column. In the last join you accidentally used the alias for the first table and not the third one. If you used OrderID, CustomerID etc. instead of ID, you would get a syntax error because the first table doesn't contain that column. If you use ID it would happily join incorrectly.