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 always prefer the option in example 1, in which the table name is (redundantly) used in the column name. This is because I prefer to see ON user.user_id = history.user_id than ON user.id = history.user_id in JOINs.

However, the weight of opinion on this issue generally seems to run against me here on Stackoverflow, where most people prefer example 2.

Incidentally, I prefer UserID to user_id as a column naming convention. I don't like typing underscores, and the use of the underscore as the common SQL single-character-match character can sometimes be a little confusing.

Answer 3

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.

Answer 4

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 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

In response to Tomas' answer, there will still be ambiguity assuming that the PK for the comment table is also named id .

In response to the question, Example 1 gets my vote. [table name]_id would actually remove the ambiguity.

Instead of

SELECT u.id AS user_id, c.id AS comment_id FROM user u JOIN comment c ON u.id=c.user_id

I could simply write

SELECT user_id, comment_id FROM user u JOIN comment c ON u.user_id=c.user_id

There's nothing ambiguous about using the same ID name in both WHERE and ON . It actually adds clarity IMHO.

Answer 7

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 8

I would suggest example 2. That way there is no ambiguity between foreign keys and primary keys, as there is in example 1. You can do for instance

SELECT * FROM user, comment WHERE user.id = comment.user_id

which is clear and concise.

The third example is redundant in a design where all id's are used as primary keys.

Answer 9

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 ie 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 10

I don't disagree with what most of the answers note - just be consistent. However, I just wanted to add that one benefit of the redundant approach with user_id allows for use of the USING syntactic sugar. If it weren't for this factor, I think I'd personally opt to avoid the redundancy.

For example,

SELECT *
FROM user
INNER JOIN subscription ON user.id = subscription.user_id

vs

SELECT *
FROM user
INNER JOIN subscription USING(user_id)

It's not a crazy significant difference, but I find it helpful.