我总是使用单数，因为这就是我所学到的。然而，在最近创建一个新的模式时，这是很长一段时间以来的第一次，我积极地决定保持这种惯例，因为。。。它更短。对我来说，在每个表名的末尾添加“s”和在每个表的前面添加“tbl_”一样无用。

如果你去那里会有麻烦，但如果你留下来，麻烦就会加倍。

我宁愿违背一些假定的非复数命名惯例，也不愿用可能是保留词的名称来命名我的表。

表格：复数

用户表中列出了多个用户。

型号：单数

可以从用户表中选择单个用户。

控制器：复数

http://myapp.com/users将列出多个用户。

无论如何，这是我的看法。

单数的我不相信任何涉及最合乎逻辑的论点——每个人都认为自己的偏好最合乎逻辑。无论你做什么，这都是一团糟，只要选择一个惯例并坚持下去。我们正试图将一种语法和语义高度不规则的语言（正常的口语和书面语言）映射到一种具有非常特定语义的高度规则（SQL）语法。

我的主要论点是，我不认为表格是一个集合，而是一个关系。

因此，AppUser关系告诉哪些实体是AppUsers。

AppUserGroup关系告诉哪些实体是AppUserGroups

AppUser_AppUserGroup关系告诉AppUsers和AppUserGroups是如何关联的。

AppUserGroup_AppUserGroup关系告诉AppUserGroups和AppUserGroup是如何关联的（即组中的组成员）。

换句话说，当我想到实体以及它们是如何关联的时候，我想到的是单数的关系，但当然，当我想起集合或集合中的实体时，集合或集合是复数的。

在我的代码和数据库模式中，我使用单数。在文本描述中，为了提高可读性，我最终使用了复数形式，然后使用字体等将表/关系名称与复数形式区分开来。

我喜欢认为它是混乱的，但有系统的——这样，我想表达的关系总是有一个系统生成的名称，这对我来说非常重要。

我更喜欢使用未选择的名词，它在英语中恰好是单数。

影响表名的数量会导致正交问题（正如许多其他答案所示），但选择这样做是因为表通常包含多行，在语义上也充满了漏洞。如果我们考虑一种基于大小写对名词进行屈折的语言（就像大多数语言一样），这一点就更明显了：

既然我们通常都在处理行，为什么不把名字放在宾格中呢？如果我们有一个写得比读得多的表，为什么不把这个名字放在与格中呢？这是一张桌子，为什么不使用属格呢？我们不会这样做，因为表被定义为一个抽象容器，无论其状态或用途如何，它都存在。在没有确切和绝对的语义原因的情况下影响名词是在胡言乱语。

使用未选择的名词是简单、逻辑、规则和语言独立的。

在寻找良好的命名惯例时，我应该如何命名会出现以下困惑：

1） 根据桌子上的东西用户表。它总是复数形式。所以，用户

2） 根据记录的内容用户表中的记录将是单个用户。SO，用户。

现在，主要是用户角色的问题。情况1：根据第一命名约定，users_roles此名称的含义、用户及其角色。

案例2：根据第二种命名约定，user_role这个名字意味着什么，用户和他的角色。

良好的命名约定是提供实体关系的额外概念，尤其是当存储多对多关系时。

在这里，根据场景，我们应该确定为一组信息。

在用户表中，形成的所有集合都是唯一的用户。在“角色”表中，形成的所有集合都是唯一的角色。在用户和角色关系表中，可以用不同的角色组成用户集，这给出了存储1个任意关系的概念。

I would prefer,
Users table => user
Roles table => role
users role relationship table => user_roles