views:

98

answers:

9

Hi,

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.

A: 

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/

DJ Quimby
very similar to how I do it - thanks for sharing this!
Mark Blades
A: 

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.

Tomas
Hey Sorry, I prefer tablename_id only :p
org.life.java
there is confusion. select c.id, o.id from customer c inner join orders o on c.id = o.cid; Two columns both with the name id so one will be id the other id1 - see my post
f00
+4  A: 

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.

InSane
this method isnt consistent. select c.id, o.id from customer c inner join orders o on c.id = o.cid. What will be the names of the two fields output by this query ? So you have to alias, therefore you can be inconsistent in your alias naming conventions
f00
@f00 - When i mentioned consistency, i was referring to being able to rely on the fact that the "id" column in any table in the database stands for the same things across tables. Regarding your point about aliases, there would usually be a standard for alias names as well in the naming conventions
InSane
@InShane - standards aside, having to alias leaves room for discrepency especially when you have more than one person working on the project. As far as being confused as to whether customer.cust_id vs. customer.id is the primary key i couldnt nor would dare attempt to comment.
f00
+2  A: 

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.

Larry Lustig
+1 you're so right, consistency is KING, id is far from being a consistent convention
f00
+1  A: 

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.

Randy
A: 

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.

Martin
A: 

Good to see a creative exchange of ideas here.. please keep them coming!

Mark Blades
A: 

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.

f00
A: 

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.

HLGEM