Learn SQL Naming Conventions
Learn SQL Naming Conventions
com/learn-sql-naming-conventions/
Quest Software and its affiliates do NOT sell the Personal Data you
provide to us either when you register on our websites or when you
do business with us. For more information about our Privacy Policy
and our data protection efforts, please visit GDPR-HQ
1 of 11 21/09/2023, 11:46
Learn SQL: Naming Conventions https://www.sqlshack.com/learn-sql-naming-conventions/
A naming convention is a set of unwritten rules you should use if you want to increase the read‐
ability of the whole data model. Today, I’ll try to explain how you should formulate your naming
convention and, maybe even more important, why should you do it and what is the overall ben‐
efit from using it.
This time we won’t talk about the data itself, but rather about the database objects and the way
they were named.
I’ve already stated it in the intro, but more generally, a naming convention is a set of rules you
decide to go with before you start modeling your database. You’ll apply these rules while nam‐
ing anything inside the database – tables, columns, primary and foreign keys, stored proce‐
dures, functions, views, etc. Of course, you could decide to only set naming convention rules for
tables and column names. That part is completely up to you.
Also, using the naming convention is not the rule, but it’s desired. While most rules are pretty
logical, you could go with some you’ve invited (e.g., you could call a primary key attribute “id”, or
“ID”), and that is completely up to you. In this article, I’ll try to use these rules you’ll meet in most
cases.
This website uses cookies. By continuing to use this site and/or
clicking the "Accept" button you are providing consent Accept
Why should you use the naming convention?
Quest Software and its affiliates do NOT sell the Personal Data you
Maybe the most important reason to use it is to simplify life to yourself. Databases rarely have a
provide to us either when you register on our websites or when you
small number of tables. Usually, you’ll have hundreds of tables, and if you don’t want to have a
do business with us. For more information about our Privacy Policy
complete mess, you should follow some organizational rules. One of these rules would be to
and our data protection efforts, please visit GDPR-HQ
apply a naming convention. It will increase the overall model readability, and you’ll spend less
2 of 11 21/09/2023, 11:46
Learn SQL: Naming Conventions https://www.sqlshack.com/learn-sql-naming-conventions/
apply a naming convention. It will increase the overall model readability, and you’ll spend less
time finding what you need. Also, it will be much easier to query the INFORMATION_SCHEMA
database in search of specific patterns – e.g., checking if all tables have the primary key at‐
tribute named “id”; do we have a stored procedure that performs an insert for each table, etc.
If that wasn’t enough, there is also one good reason. The database shall live for a long time.
Changes at the database level are usually avoided and done only when necessary. The main
reason is that if you change the name of the database object that could affect many places in
your code. On the other hand, the code can change during time. Maybe you’ll even change the
language used to write the code. Therefore, you can expect that the database will stay, more or
less, very similar to its’ initial production version. If you apply best practices from the start and
continue using them when you add new objects, you’ll keep your database structure well orga‐
nized and easily readable.
One more reason to use it is that you probably won’t be the only one working with the database.
If it’s readable, anybody who jumps into the project should be aware of what is where and how
the data is related. That shall be especially the case if you’re using the most common naming
convention rules. In case you have something specific for your database, you can list all such
exceptions in one short document.
When naming tables, you have two options – to use the singular for the table name or to use a
plural. My suggestion would be to always go with names in the singular.
If you’re naming entities that represent real-world facts, you should use nouns. These are tables
like employee, customer, city, and country. If possible, use a single word that exactly de‐
scribes what is in the table. On the example of our 4 tables, it’s more than clear what data can
be found in these tables.
Hint: Use singular for table names (user, role), and not plural (users, roles). The plural
could lead to some weird table names later (instead of user_has_role, you would have
users_have_roles, etc.)
3 of 11 21/09/2023, 11:46
Learn SQL: Naming Conventions https://www.sqlshack.com/learn-sql-naming-conventions/
Imagine that we have tables user and role. We want to add a many-to-many relation telling us
that a user had a certain role. We could use names user_has_role, or if we want to be shorter
– user_role.
We could always make exceptions if they are logical. If we have tables product and invoice,
and we want to specify which products were on which invoice, we could name that table in‐
voice_product or invoice_contains_product. Still, using the name invoice_item is much
closer to the real world. Still, that decision is completely up to you.
• A primary key column. You should usually have only 1 column serving as a primary key.
It would be the best to simply name this column “id”. You should also name your PK con‐
straint in a meaningful way. E.g., in our database, the PK of the call table is named
call_pk
4 of 11 21/09/2023, 11:46
Learn SQL: Naming Conventions https://www.sqlshack.com/learn-sql-naming-conventions/
Hint: It’s not a problem if two columns, in different tables in the database, have the same
name. Still, having unique names for each column is OK because we reduce the chance
to later mix these two columns while writing queries
• Dates. For dates, it’s good to describe what the date represents. Names like start_date
and end_date are pretty descriptive. If you want, you can describe them even more pre‐
cise, using names like call_start_date and call_end_date
• Flags. We could have flags marking if some action took place or not. We could use
names like is_active, is_deleted
Foreign keys. You should name them in such a manner that they uniquely and clearly describe
what they are – which tables they relate. In our database, the foreign key that relates tables call
and call_outcome is called call_call_outcome.
Quest Software and its affiliates do NOT sell the Personal Data you
provide to us either when you register on our websites or when you
do business with us. For more information about our Privacy Policy
and our data protection efforts, please visit GDPR-HQ
5 of 11 21/09/2023, 11:46