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

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

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

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

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

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

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

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

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

我坚持表名和任何编程实体使用单数。

原因是什么？事实上，英语中有不规则的复数形式，如mouse⇒ 老鼠和绵羊⇒ 羊然后，如果我需要收集，我只需要使用老鼠或绵羊，然后继续。

这确实有助于多元性脱颖而出，而且我可以通过编程轻松地确定这些东西的集合是什么样子的。

所以，我的规则是：所有事物都是单数，所有事物的集合都是单数的，并加上s。也有助于ORM。

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

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

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

AppUserGroup关系告诉哪些实体是AppUserGroups

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

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

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

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

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

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

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

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

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