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 entire

Answer 1

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 2

table users (plural):

• id
• name
• age

plain and simple.

Answer 3

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 4

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

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.