我也会使用复数形式，对于前面提到的用户困境，我们确实采用了方括号方法。

我们这样做是为了在数据库体系结构和应用程序体系结构之间提供一致性，基本上理解为用户表是用户值的集合，就像代码工件中的用户集合是用户对象的集合一样。

让我们的数据团队和开发人员使用相同的概念语言（尽管不总是相同的对象名称），可以更容易地在他们之间传达想法。

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

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

我只是说说我为什么用单数名。

例如，我需要从用户处获取所有字段：

-- Select every fields from 'user' table
SELECT * FROM user

我需要21岁用户的姓名：

-- Select every fields from 'user' table which have 21 years old
SELECT * FROM user WHERE age = '21'

当然，复数形式也可以用同样的方式，但对于我的大脑来说，我真的认为这是正确的方式。

实际上，我一直认为使用多个表名是一种流行的习惯。到目前为止，我一直使用复数。

我可以理解单数表名的论点，但对我来说，复数表名更有意义。表名通常描述表包含的内容。在标准化数据库中，每个表都包含特定的数据集。每一行都是一个实体，表中包含许多实体。因此，表名的复数形式。

一张汽车表上会有汽车的名字，每一排都是一辆汽车。我承认，以table.field的方式指定表和字段是最好的做法，使用单一的表名更容易阅读。然而，在以下两个例子中，前者更有意义：

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

老实说，我将重新思考我在这件事上的立场，我将依赖于我正在开发的组织所使用的实际惯例。然而，我认为出于个人习惯，我将坚持使用复数表名。对我来说，这更有意义。

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

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

什么约定要求表具有单数名称？我一直以为是复数。

用户将添加到“用户”表中。

本网站同意：http://vyaskn.tripod.com/object_naming.htm#Tables

本网站不同意（但我不同意）：http://justinsomnia.org/writings/naming_conventions.html

正如其他人所提到的：这些只是指导方针。选择一个适合你和你的公司/项目的惯例，并坚持下去。在单数和复数之间切换，或者有时缩写词，有时不缩写词，这会让人更加恼火。