jream — 2010-03-20T11:58:45-04:00 — #1
I was watching a few tutorials and wondered if this is good practice or not.
This guy made two tables, one called Users the other called Content.
His primary keys were named:
users_id for Users table
content_id for Content table
He suggested this to avoid conflict with the Primary Key on a JOIN.
I know you can just alias it which I prefer right now.
Which one is better practice? Or does it not matter?
dan_grossman — 2010-03-20T12:02:41-04:00 — #2
It doesn't matter, it's like camel case vs. underscores, a preference.
jream — 2010-03-20T13:40:34-04:00 — #3
oddz — 2010-03-20T13:45:07-04:00 — #4
That is a conventional rule that all developers must apply to were I work. I remember thinking it was worthless when I began working there but as time has progressed I have seen it to be very useful for the reasons you stated. Although you might not think so that convention makes complex joins and queries in general easier to comprehend. However, as Dan stated its a personal preference.
r937 — 2010-03-20T14:50:30-04:00 — #5
i have seen thousands of very complex joins and queries and i still don't think it's a good idea to embed the entity name into the column name
speaking of camels, the fable of the camel's nose in the tent comes to mind...
if you prefer user_id instead of id for the users table, then shirley you will also prefer this --
CREATE TABLE users
( user_id INTEGER NOT NULL PRIMARY KEY
, user_name VARCHAR(16) NOT NULL
, user_pswd VARCHAR(16) NOT NULL
, user_fullname VARCHAR(99) NOT NULL
, user_email VARCHAR(99) NOT NULL
to this --
CREATE TABLE users
( id INTEGER NOT NULL PRIMARY KEY
, name VARCHAR(16) NOT NULL
, pswd VARCHAR(16) NOT NULL
, fullname VARCHAR(99) NOT NULL
, email VARCHAR(99) NOT NULL
where do you draw the line? and if you say okay, draw the line at "id" then my question is why stop there?
yes, it is a personal preference, isn't it
force — 2010-03-20T18:47:32-04:00 — #6
I tend to use user_id or uid or the user id. It helps eliminate confusion in my mind as to which id it is. The rest of the fields...I just make reasonably descriptive so they make sense at a glance. That's probably the most important thing.
After all, I don't think most folks would use something like ZipBingWhee_id as the user id. Unless that one makes sense to you...
rageh — 2010-03-20T20:44:43-04:00 — #7
id is an id. I am begining to doubt whether using user_id is more useful than plain id.
dan_grossman — 2010-03-20T20:49:02-04:00 — #8
If you are going to call the foreign key in the other table user_id, then you're going to have to specify the table name or alias in the join either way, so you add verbosity without much benefit.
"ON user_id = user_id" is going to be ambiguous, "ON id = user_id" will be too if both tables have an id, so you'll end up with "ON users.id = posts.user_id" regardless of the choice you made... so the longer name didn't help.
If I need an artificial identifier, I use "id". I switched from camel case (userId) to underscore (user_id) some years ago for foreign keys, mainly because it's easier to read quickly, and a good convention if you're ever going to use an ORM. Many of them default to underscores as the column names become machine parseable (split at underscore, left side is the type of object the FK references).
r937 — 2010-03-20T21:35:55-04:00 — #9
on the contrary, it is vital (in my opinion) that in any query of more than one table (i.e. a join) that every column used in the query be qualified with its table name (or table alias)
this, to me, is not a matter of preference, it is mandatory, and essential to understanding the query