如果您使用Zend Framework（PHP）等特定框架，那么明智的做法是表类使用复数，行类使用单数。

因此，假设您创建了一个表对象$users=newUsers（），并将行类声明为User，那么您也可以调用newUser（）。

现在，如果对表名使用单数，则必须执行类似于newUserTable（）的操作，其中的行是newUserRow（）。对我来说，这看起来比为表设置对象Users（）和为行设置User（）对象更笨拙。

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

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

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

AppUserGroup关系告诉哪些实体是AppUserGroups

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

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

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

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

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

IMHO，表名应该是复数，如Customer。

如果类名称映射到Customers表中的一行，则类名称应与Customer类似。

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

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

我坚信，在实体关系图中，实体应该用一个单数名称来反映，类似于类名是单数。实例化后，名称将反映其实例。因此，对于数据库，当实体被制成表（实体或记录的集合）时，它是复数。实体，用户被制成表用户。我同意其他人的建议，也许User这个名字可以改为Employee，或者更适合您的场景。

这在SQL语句中更有意义，因为您正在从一组记录中进行选择，如果表名是单数，则读起来不好。

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