Table Name

A naming convention is a set of rules (written or unwritten) used to improve the readability of a data model. You can apply these rules when naming anything in your database, including tables, columns, primary and foreign keys, stored procedures, functions, views, and more. But you don't need to apply the rule to all database objects. For example, apply naming convention rules to table and column names only. It's all up to you, as using a naming convention is not mandatory, but still has its benefits. This three-part series of articles will introduce some commonly used naming conventions and explain some tips for making your own naming conventions. Part 1 of the article will cover table names, while Part 2 will focus on column names. Finally, Part 3 introduces naming conventions for other database objects, such as foreign keys, procedures, functions, and views.

Why use a naming convention

Very few databases have only a small number of tables. And in fact, it is not uncommon to have hundreds of tables. So following the naming convention can improve the overall readability of the model and make it easier to find database (DB) objects, helping you get the job done easily.

Another good reason is that databases evolve slowly and continuously over time. Although you generally avoid changing its schema and only make changes when necessary, changing the name of a database object can affect your application code in a number of ways. Since you can expect the database to remain more or less very similar to how it started, if you take best practice from the start and continue to use it as you add new objects, your database structure will change over time. Keep it well organized.

Singular and plural table names

One of the most common questions about table naming is whether to use singular or plural forms. There are many different opinions on this issue. In fact, we can see that the schemas of MySQL classicmodels and sakila sample databases are named in these two ways, the former uses plural table names, and the latter uses singular names:

Most DBAs use singular names if it helps them work. One reason is that plural names like "users", "roles" can lead to some weird table names like "users_have_roles" instead of "user_has_role".

Describe real-world entities

Anytime you name entities that represent real-world things, you should use their proper names. This applies to tables like employee, customer, city, country, etc. Usually, one word should describe exactly what's in the table.

Sometimes you have to use more than one word to describe the contents of the table. An example of this can be seen in the classicmodels database. There is a table "orders" and another table "order_details":

orders table

order_details 表

"order_details" has data about ordered products, such as the quantity ordered and the price. The table could be named "product_details", but that doesn't convey that the product is associated with an order.

named related table

For a relationship between two tables, it is standard practice to use the names of the two tables. It is also possible to add a verb between the two names to describe what the action is, such as "user_has_role", or simply "user_role". The Sakila sample database uses this convention to join related tables with an intermediate table that combines the two names. We can see two examples in the database model below - "film_actor" and "film_category":

Conclusion on Table Naming Conventions in SQL

Don't be afraid to give up using a naming convention if it doesn't make logical sense in a particular situation. For example, if we have a product and invoice table, and we want to specify which products go on which invoices, the name "invoice_item" might make more sense than "invoice_product" or "invoice_contains_product".

A Quick Guide to Naming Conventions in SQL - Part 1