The 11 Worst Database Naming Conventions I’ve Seen in Real Life

What – I can’t just let it be called Table_1?

After decades of working with databases, I’ve come across all kinds of naming conventions in database modeling, with varying degrees of usefulness. Some conventions are a great help when working with a database. Others are just a big headache.

When designing a data model, object names’ readability is an important consideration. A robot might not agree to this, as all names are equally easy for a robot to remember and to locate in a complicated SQL script. Furthermore, the robot does not need to associate the name of an object with something that it remembers. Database design tools, such as the Vertabelo platform, make it easy to locate objects in a model regardless of its size. But still, humans need some help to memorize names, to write them, and to figure out the purpose of an object based on what it is called.

There’s another reason why database object names are important: once an object is created in a database, changing its name can be fatal. Altering just one letter of the name can break dependencies, relationships, and even entire systems.

That’s why it is critical to work with a healthy naming convention – a set of rules that save us the trouble of trying 50 different possibilities to find an object name that we cannot remember.

It would be great to trust that, if we work within a naming convention, we won’t find a table with an obnoxious name like My_Table_of_Products, BobsTable, Table_1, or MHX77JJK4L. But, unfortunately, life is not like that.

My Picks for the Worst Database Name Conventions

There is no universal guide to developing a useful naming convention. But many examples of bad naming conventions can be cited, some of which are even worse than no convention at all! By highlighting the bad practices I mention below, I hope to a) help you avoid them, and b) give you some peace of mind that the names you choose will keep to a uniform and successful convention.

This list of unsuccessful database naming conventions is ordered (by my personal preferences) from most to least acceptable.

#11 Underscore_for_Word_Separation

Applied to: All Object Types

If all database objects could be named using a single word, the task of choosing names would be a little easier. But the use of compound names is inevitable when a schema grows and it becomes necessary to use qualifiers to differentiate various objects – e.g. when you have to differentiate between a shipping date and an order date.

The underscore is a universally accepted character for separating words in compound names (e.g. Shipment_Date and Order_Date). But it has some disadvantages:

• Under certain display conditions, the underscore can be confused with a blank space within a command. This could lead us to believe that an object with a compound name is actually two objects or that it’s an object name followed by its alias.

If you don’t have 20/20 vision, the underscore can go unnoticed, making you believe that the second part of the name is an alias.

• Typing an underscore requires a key combination. On keyboards configured for international use, that key combination is often difficult to find, which wastes valuable typing time.
• The underscore makes object names longer and adds a character that does not provide any meaning.
• It’s a little bit old fashioned.

Personally, I’d rather use camel case to join compound names, capitalizing the first letter of each word (e.g. ShipmentDate, SupervisorName, OrderId, and so on). In my experience, this convention is more broadly accepted than using an underscore to join compound names.

# 10 ALL UPPER CASE

Applied to: All Object Types

What, did you just get off the time machine? Please, just turn off the Caps Lock key. All-uppercase is so old school.

All-caps names ruin the ability to use camel case, causing words to stick together or forcing you to revert to using underscore to separate words.

It could be argued that using all-uppercase for certain objects (like tables) helps distinguish them from other objects. But, personally, I’d pass.

#9 Singular Names

Applied to: Tables/Views

There’s a bit of a controversy among designers when it comes to choosing singular or plural forms for entity, table, and view names. Many purists defend the use of the singular, e.g. Employee, Customer, Address, etc. Their argument is that an entity is a single thing, not a set of things. However, when a model goes from logical to physical and the entity is transformed into a table, it ceases to be a single object to become a container for many instances of an object. If you are making a wooden box for your kid’s toys, would you label it "Toy" or "Toys"? Exactly.

Let’s be a little less purist and stick to plural words for entity names. At the end of the day, both designers and developers will feel more comfortable with them.

#8 Generic or Meaningless Names

Applied to: All Object Types

Sometimes when you look at a data model, you wonder where the common sense went. Any naming convention should expressly prohibit (or maybe fine?) the use of generic or meaningless names. The same should apply to misleading and ambiguous names. I’ve seen designs with names like ...

GeneralData
Config
DataTable
ImportedRecords
Flag
Scrap

... and the list goes on. Please, have a little sympathy for the poor guys who will have to read and use those data models. Side note: Stick to infinitive verbs (the basic form of a verb, such as calculate, append, or summarize) to name stored procedures. Their names should express actions, not something static.

#7 Namen in Fremdsprachen (Names in Foreign Languages)

Applied to: All Object Types

I’ve worked with databases that used German names (SAP databases, anyone?). As I don’t speak German, it has not been a pleasant experience. I have expanded my vocabulary as a result, but I would have preferred to simply deal with names that I could understand without having to use a translator.

Any naming convention should explicitly state the language to use for naming objects; preferably, it should be a language understood by the database designer!

As if it wasn’t enough to put names in another language, they are also abbreviated.

#6 PrePrefixes

Applied to: All Object Types

Prefixes can be useful in some cases. Suppose you need to group objects related to a particular application on a database that’s used for different purposes. If there’s a risk that object names may get repeated, a prefix might be a good idea.

For example, if a payroll app shares a database with a personnel control app and both use tables with the same names, it is convenient to differentiate them by adding a prefix that indicates the app to each object name. We would know that all the objects that begin with Payrl correspond to the payroll app and all that begin with Pctrl to the personnel control application. It’s not an ideal situation, but it works.

But in certain naming conventions, prefixes are used for other, not-so-successful purposes, such as identifying the type of object. Thus, we would find data models where table names start with Tbl, views with Vue, fields with Fld, and so on.

Those who adopt a convention like this may argue that the use of prefixes prevents attempts to create objects of different types with the same names. For example, if you want to name a view Products and a table Products, just add some prefixes and problem solved: the table will be called TblProducts and the view, VueProducts.

Nuh-uh. That’s not the purpose of a prefix. Instead of looking for a workaround that allows you to repeat names, you should simply think of more meaningful names for each object. Normally, a view should serve a different purpose than a table, and its name should express that difference. For example, suppose you want to extract a subset of an entity. You have an entity called Products and you want to create a view to return only imported products. Then why not call the view ImportedProducts?

Enough with prefixes? Nope. There’s more.

Another unfortunate – but fairly common – use of prefixes is to prepend an abbreviation of the entity name to all the attributes of that entity. The thinking is that this will avoid confusion among attributes with similar names in different entities. So the Name field of the Customers table becomes something like CustName and the Name field of the Employees table becomes EmplName. Nothing is more impractical and unnecessarily redundant.

It makes sense to avoid similar names in long SQL commands to make them easier to read, but that’s what aliases are for:

SELECT
    Cust.Name AS CustName,
    Empl.Name AS EmplName
FROM
    Customers AS Cust,
    Employees AS Empl,
    ...

You don’t want to distort object names in a data model just to make it easier to read or write SQL statements later. As we’ve seen, there are other ways of simplifying script writing.

Can you guess what this ERD is about? If not, at least you can identify the naming conventions that are making it difficult to figure out.

#5 Unclr Abbrev Criteria

Applied (mostly) to: Field Names

To avoid excessive verbosity, some naming conventions may enforce word abbreviation with some criterion, such as cutting words bigger than n characters or removing as many vowels as you can. That’s fine, as long as everyone is clear on how to abbreviate each term – which is highly unlikely. How should the field name ItemNumber be abbreviated? ItemNo, ItemNbr, or ItemNr?

The result of trying to impose the habit of abbreviating is that everyone uses the abbreviations most familiar to them. Then, when you try to remember a field name, you must try all the possible abbreviations until you find the correct one. It’s better to keep the words as they are, even if that makes you type a few more letters. Just turn your favorite autocomplete function on.

#4 Mandatory char lim

Applied to: All Object Types

Putting a limit on the number of characters (below what your tools impose) is pure evil. If names can be as long as you want, why limit their length?

These kinds of limitations force us to use unnatural abbreviations that are difficult to read without providing any benefit in return. And we’ll most likely have to accompany data models with a data dictionary to understand what each object is.

#3 Using Non-Standard Syntax

Applied to: All Object Types

Some relational database management systems (RDBMSs) support a syntax apart from the SQL standard. When working on a particular RDBMS, you may be tempted to use those syntax peculiarities to have more freedom when choosing names. A typical case is Transact-SQL (the version of SQL implemented in Microsoft SQL Server). Brackets are supported in Transact-SQL to enclose names that include unsupported characters. For example, a table name cannot contain spaces or periods – unless the name is enclosed in square brackets. In Transact-SQL, the statement below is valid:

SELECT * FROM [Pending Orders.Detail]

This habit causes a nefarious effect called vendor lock-in: the inability to migrate a database to a different RDBMS. If you use non-standard names for your database objects, you will have to live with the same RDBMS until you decide to do a total redesign of your databases and applications.

#2 Inconsistent_NamingConventions

Applied to: All Object Types

All of the above naming conventions may or may not be good, but at least the adopted conventions remain consistent within the same database. It’s very annoying to find names that don’t follow an established convention. Want to impose a limit on name lengths? Okay, do it. But I don’t want to see any name that exceeds that limit. Things like that make you wonder why a convention was established in the first place.

#1 Intenti0nal Obfusc4tion

Applied to: All Object Types

Finally, we’ve come to the worst naming convention of all: names created especially to hide the meaning of objects from anyone looking at the database.

This situation usually occurs when we work with a database created by a low-code or no-code development tool, or something that years ago was called a fourth-generation language (4GL). These tools try to prevent direct access to database objects. Why do this? They need to have full control over the schemas for copyright reasons and any changes made to the database structure from outside the tool may render it unusable.

So, these tools intentionally obfuscate the names of database objects, creating a real nightmare for database designers and DBAs. I’m not saying the tools are no good, but you should know that the benefits they offer come with a trade-off – and you may discover that trade-off when you try to figure out what’s in your database.

What Are Database Naming Conventions For?

Naming conventions should make life easier to designers and developers, facilitating the task of reading and writing object names. Otherwise, no one will respect them and the result will be chaotic databases with meaningless names.