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

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

-- 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名称是表结构的一个定义。VIEW或QUERY名称是（一个或多个）表的视图或查询的一个定义。表格、视图或查询可能包含以下内容之一：

0条记录1条记录许多记录。

你到底为什么要在一个对象名称的末尾加一个“s”？将“s”放在对象名称的末尾，表示什么意思？

如果要区分，请添加“_tbl”。视图是“_vew”（而不是愚蠢的“_v”约定）。

最少3个字符的后缀-这会使讨论停止。

表是一个DB对象，与其他对象没有区别。

保存3个字符只会使意思清晰。

红色；-）

我一直认为那是一个愚蠢的惯例。我使用多个表名。

（我相信这一策略背后的原因是，它使ORM代码生成器更容易生成对象和集合类，因为从单数名称生成复数名称比从单数名称中生成复数名称更容易）

如果您使用对象关系映射工具，或者将来会使用，我建议您使用Singular。

一些工具（如LLBLGen）可以自动更正多个名称（如用户到用户），而无需更改表名本身。为什么这很重要？因为当它被映射时，你希望它看起来像User.Name而不是User.Name，或者更糟糕的是，我的一些旧数据库表命名为tblUsers.strName，这在代码中令人困惑。

我的新经验法则是判断它转换成对象后的外观。

我发现一个不适合我使用的新命名的表是UsersInRoles。但总会有一些例外情况，即使在这种情况下，它看起来也很像UsersInRoles.Username。

就“标准”而言，其他人给出了相当好的答案，但我只是想补充一下。。。是否可能“用户”（或“用户”）实际上不是表中数据的完整描述？并不是说你应该对表名和特定性太着迷，但也许像“Widget_Users”（其中“Widget”是应用程序或网站的名称）这样的东西会更合适。

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

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

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

AppUserGroup关系告诉哪些实体是AppUserGroups

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

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

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

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

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