A common debate in relational database circles is whether the names
of tables should be singular or plural. If you have a table that
stores users, should the table be called user or users?
在关系型数据库领域，一个常见的争论是表的名称应该是单数还是复数。如果你有一个存储用户的表，表名应该是 user 还是 users ？
The arguments for plural are straightforward:
使用复数的理由很简单：
The table is storing more than one user.
这个表存储了多个用户。
It reads well in the FROM clause:
在 FROM 子句中读起来很顺畅：
SELECT id, name
FROM users;
The arguments for singular are more subtle:
使用单数名词的理由更为微妙：
Strictly speaking, we’re not naming a table, we’re naming
a relation. We’re describing the relationship between the
user’s ID, their name, their address, and so on. And there’s
only one relation for user data. It happens that once
we’ve described the user relation, we can use it for
many users.
严格来说，我们不是在命名一个表，而是在命名一个关系。我们在描述用户 ID、他们的名字、地址等之间的关系。并且对于用户数据只有一个关系。碰巧一旦我们描述了 user 这个关系，就可以用它来表示多个用户。
It reads well everywhere else in the SQL query:
在 SQL 查询的其余部分读起来也很顺畅：
SELECT id, name
FROM user
JOIN country ON user.country_id = country.id
WHERE country.name = 'Canada';
That would make less sense if the ON clause read users.country_id.
如果 ON 子句读作 users.country_id ，那就更没有意义了。
The name of the class you’ll store the data into is
singular (User). You therefore have a mismatch, and in
ORMs (e.g., Rails) they often automatically pluralize,
with the predictable result of seeing tables with names
like addresss.
你要存储数据的类的名称是单数的（User）。因此存在不匹配，在 ORMs（例如 Rails）中，它们通常会自动复数化，结果就是看到类似 addresss 的表名。
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?
有些关系已经是复数的。假设你有一个名为 UserFacts 的类，用于存储关于用户的各种信息，比如年龄和喜欢的颜色。你会怎么命名数据库表？
The last argument above is the strongest, because it only
takes one such exception to wreck an entire schema’s
consistency. You won’t run into problems with singular,
now or later.
上面最后一个论点是最强的，因为它只需要一个这样的例外就能破坏整个模式的完整性。你现在或将来都不会遇到单数的问题。