When it comes to database table names, software engineers will always debate whether they should be singular or plural. In Tandem’s #development Slack channel, we conducted a poll about everyone’s preference for database table names. Of the six Tandemites who responded, four preferred pluralized and two preferred singular. A lengthy exchange ensued, complete with screenshots!
It’s clear that this topic can inspire a lot of passion, and both sides have compelling arguments. Let’s take a look at the reasoning behind using singular or plural database table names:
Singular Database Table Names
Proponents of singular database table names contend that they are easier to follow. For example, once you know you are dealing with
User, you will know to use that same word for all interaction needs in the database. It’s also seen as more aesthetically pleasing because it reads better in one-to-one relationships, like when a
User has a
Singular database table names are also seen as more inclusive of developers who are non-native English speakers, as remembering the plural versions of words can often be challenging — especially for words like
tomatoes). Because of English’s weirdness, some would say that singular database table names save time because developers don’t have to sit and think about what the proper plural name is for
tomato. Not typing the extra two letters to make
tomato plural means less time spent writing. And with fewer typos, there are fewer errors overall.
Naming will always get tricky with naturally pluralized words. For example, there may be a
User that has
Preferences, with a table containing multiple pieces of information like
display_military_time, etc. When we talk about preferences, we mean a “set of preferences,” so
UserSetofPreferences is singular and
UsersSetsofPreferences is plural. However, to be more clear and concise, we would say
UsersPreferences because the set or sets is implied.
In this case,
UserPreferences is singular because it’s a singular set of preferences — one single row is a user’s preferences. On the other hand,
UsersPreferences means users’ preferences, which is plural because it involves more than one set of preferences. However, some will argue that
UserPreferences is still an inherently plural relation, meaning that plurality is unavoidable for those using singular naming conventions.
Let’s take a look at some of the arguments for plural database table naming.
Plural Database Table Names
There are two sides to every coin, and so there will always be engineers who claim that plural database table names are better than singular. Many developers claim that plural names provide uniformity across code and storage and between database architecture and application architecture. For example, each row in a table is an instance of a thing, and the table contains many things. With this logic, if there are multiple instances of the thing, like a
user record, the table should be plural because it represents a group of users, not a group of user.
The language is a way to conceptualize the table, which is essentially a bucket with things of that type in it. A metaphor that many developers use for this concept is if you have a box of apples, you wouldn’t label it “apple,” even if there was only one apple in it — you would label it “apples.” Applying this philosophy to a database table, some may say that naming a collection of user objects
user in code blurs the distinction between what is in the table versus the table itself. Many developers use plural database table names because that’s what the framework convention expects.
So Which Should I Use: Singular or Plural?
The correct answer is that there is no right or wrong when naming database tables — just be consistent from the start. The only wrong answer with database table names is to use a combination of plural and singular. It’s easier for your team to remember one or the other once and stick to it.
It’s important to remember that our opinions are based on our experiences — developers’ opinions about naming come from their backgrounds. People often use singular or plural names because that’s what they are used to and have always done. At Tandem, we have a deep history with Ruby on Rails, so we internalize that experience by mostly using plural database table names.
Outside the world of Rails, there isn’t always plural. Rails has a dedicated convention to its own rules that don’t apply everywhere else.
Octopi because it is built into the framework. We acknowledge and respect that using one way of naming over the other will not work for everyone. There are no pros or cons to using singular or plural database table names — it all comes down to preference.
Ultimately, there are no rules with database table naming. People make them up, and the best thing you can do is stick to them so your data makes sense to the maintainers of the codebase. Consistency is the unspoken rule, much like separating words with underscores in a schema — but that’s a discussion for another time! 😉