"For most SQL code, your safest bet is to never use any English language word as the name of a user-defined object...

"SQLite adds new keywords from time to time when it takes on new features. So to prevent your code from being broken by future enhancements, you should normally quote any identifier that is an English language word, even if you do not have to."

https://sqlite.org/lang_keywords.html

All arguments seem pretty frail, always reduced to some form of "well this way makes it easier for ME to reason about!". I used to have opinions on this crap, and nowadays I've got way bigger fish to fry than worrying about table name plurality. As long as it's human-legible and consistent, who cares?

And a relation is a set, hence plural.

2. It reads well everywhere else in the SQL query:

   SELECT Employee.Name
        , Manager.Name
     FROM Users AS Employee
        , Users AS Manager
    WHERE Employee.ManagerID = Manager.ID
      AND Employee.DateOfBirth IS NULL;

The class User represents a single row, not the entire table, hence singular. If the O/R mapper or some other tooling has issues with singular and plural, then I agree, it might not be worth fighting the tools.

4. Some relations are already plural. Say you have a class called UserFacts that store miscellaneous information about a user, like age and favorite color. What will you call the database table?

I think having the table and the class name both in plural would be fine. That also seems rare enough in practice that I would not let this dictate the decision. In the given example I would also tend to record the user facts as a list of them. A user fact is a key value pair associated with an user, the keys living in their own table. Having the keys implicit as column names will also make some queries unnecessarily complicated and as the number of facts grows, the table will become increasingly wide.

Also sometimes we have singular names for collections of things, then it is fine to have a singular table name, you can name your Trees table Forrest if that makes sense in the domain.

For me, it's in the same category as preferring generated primary keys were named <table-name>_id over just "id" - you may have a preference, but it's not got that much big picture importance.

Some DB engines won't let you use a keyword as identifiers for anything unless it's quoted, and then you either have to quote everything, or end up in a weird situation where some things are quoted and some aren't.

  SELECT *
  FROM customer
  JOIN order USING (customer_id)

For example we have a table "customer_data" at work and in our generated ORM code it's called "customer_datum".

The open-source singularization library is doing its job, but it sure made it difficult for me to global-search for that object name when I joined the company and didn't know the object was called that.

    customers
    customer_attributes
    customers_labels

After you've got three or so words in a table name it really becomes inconsistent and you can't really guess what they're called when writing code.

There are solutions of course: whether to use the "s" on join tables could be a policy documented somewhere and everyone, including new employees, could be made aware of it. But it's a problem you don't have if you use singular table names.

* PostgreSQL system table names are singular e.g. "pg_class"

* Oracle system tables are plural e.g. "ALL_TABLES"

* MySQL is also plural e.g. "schemata".

I skimmed classic Codd paper "A relational model of data for large shared data banks" which gave birth to RDMS.

Codd uses singular nouns for example relation names: PART, PROJECT, COMMIT, supply, component, employee, jobhistory, salaryhistory. The only exception is "children" relation.

So that's one small argument in favour of singular approach :)

> select * from "user"

which is ugly

I like tabs, most pick spaces

I like mercurial, most pick git

But no one’s taking my vim!