Sql naming best practice

Question

I'm not entirely sure if there's a standard in the industry or otherwise, so I'm asking here.

I'm naming a Users table, and I'm not entirely sure about how to name the members.

user_id is an obvious one, but I wonder if I should prefix all other fields with "user_" or not.

user_name user_age

or just name and age, etc...

Answer 1

Just go with name and age, the table should provide the necessary context when you're wondering what kind of name you're working with.

Answer 2

Look at it as an entity and name the fields accordingly

I'd suggest a User table, with fields such as id, name, age, etc.

A group of records is a bunch of users, but the group of fields represents a user.

Thus, you end up referring to user.id, user.name, user.age (though you won't always include the table name, depending on the query).

Answer 3

prefixes like that are pointless, unless you have something a little more arbitrary; like two addresses. Then you might use address_1, address_2, address_home, etc

Same with phone numbers.

But for something as static as age, gender, username, etc; I would just leave them like that.

Just to show you If you WERE to prefix all of those fields, your queries might look like this

SELECT users.user_id FROM users WHERE users.user_name = "Jim"

When it could easily be

SELECT id FROM users WHERE username = "Jim"

Answer 4

For the table names, I usually use pluralized nouns (or noun phrases), like you.

For column names I'd not use the table name as prefix. The table itself specifies the context of the column.

Greets Flo

Answer 5

It's personal preference. The best advice we can give you is consistency, legibility and ensuring the relationships are correctly named as well.

Use names that make sense and aren't abbreviated if possible, unless the storage mechanism you are using doesn't work well with them.

In relationships, I like to use Id on the primary key and [table_name]_Id on the foreign key. eg. Order.Id and OrderItem.OrderId

Id works well if using a surrogate key as a primary key.

Also your storage mechanism may or may not be case sensitive, so be sure to that into account.

Edit: Also, thre is some theory to suggest that table should be name after what a single record in that table should represent. So, table name "User" instead of "Users" - personally the plural makes more sense to me, just keep it consistent.

Answer 6

I agree with the other answers that suggest against prefixing the attributes with your table names.

However, I support the idea of using matching names for the foreign keys and the primary key they reference¹, and to do this you'd normally have to prefix the id attributes in the dependent table.

Something which is not very well known is that SQL supports a concise joining syntax using the USING keyword:

CREATE TABLE users (user_id int, first_name varchar(50), last_name varchar(50));
CREATE TABLE sales (sale_id int, purchase_date datetime, user_id int);

Then the following query:

SELECT s.*, u.last_name FROM sales s JOIN users u USING (user_id);

is equivalent to the more verbose and popular joining syntax:

SELECT s.*, u.last_name FROM sales s JOIN users u ON (u.user_id = s.user_id);

---

¹ This is not always possible. A typical example is a user_id field in a users table, and reported_by and assigned_to fields in the referencing table that both reference the users table. Using a user_id field in such situations is both ambiguous, and not possible for one of the fields.

Answer 7

First of all, I would suggest using the singular noun, i.e. user instead of users, although this is more of a personal preference.

Second, there are some who prefer to always name the primary key column id, instead of user_id (i.e. table name + id), and similar with for example name instead of employee_name. I think this is a bad idea for the following reason:

-- when every table has an "id" (or "name") column, you get duplicate column names in the output:
select e.id, e.name, d.id, d.name
from employee e, department d
where e.department_id = d.id

-- to avoid this, you need to specify column aliases every time you query:
select e.id employee_id, e.name employee_name, d.id department_id, d.name department_name
from employee e, department d
where e.department_id = d.id

-- if the column name includes the table, there are no conflicts, and the join condition is very clear
select e.employee_id, e.employee_name, d.department_id, d.department_name
from employee e, department d
where e.department_id = d.department_id

I'm not saying you should include the table name in every column in the table, but do it for the key (id) column and other "generic" columns such as name, description, remarks, etc. that are likely to be included in queries.

Answer 8

As other answers suggest, it is a personal preference - pick up certain naming schema and stick to it.
Some 10 years ago I worked with Oracle Designer and it uses naming schema that I like and use since then:

• table names are plural - USERS
• surrogate primary key is named as singular of table name plus '_id' - primary key for table USERS would be "USER_ID". This way you have consistent naming when you use "USER_ID" field as foreign key in some other table
• column names don't have table name as prefix.

Optionally:

• in databases with large number of tables (interpret "large" as you see fit), use 2-3 characters table prefixes so that you can logically divide tables in areas. For example: all tables that contain sales data (invoices, invoice items, articles) have prefix "INV_", all tables that contain human resources data have prefix "HR_". That way it is easier to find and sort tables that contain related data (this could also be done by placing tables in different schemes and setting appropriate access rights, but it gets complicated when you need to create more than one database on one server)

Again, pick naming schema you like and be consistent.

Answer 9

table users (plural):

• id
• name
• age

plain and simple.