表的SQL定义实际上是表的一个潜在行的定义，而不是集合。因此，该定义中使用的名称必须指定行的类型，而不是集合的名称。那些喜欢复数的人，因为它在他们的英语语句中读起来很好，他们需要开始更逻辑地思考，并查看实际使用表所涉及的所有逻辑和编程代码。这些注释中提到了使用单数表名的几个很好的理由。其中包括不使用多个表名的充分理由。“好好读书”根本不应该是任何理由，尤其是因为有些人可能会以不同的方式来理解这个想法。

我的看法是语义上的，这取决于您如何定义容器。例如，“一袋苹果”或简单的“苹果”或“苹果袋”或“apple”。

例子：“学院”表可以包含0个或多个学院“学院”表可以包含0个或多个学院

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

我的结论是，两者都可以，但你必须定义你（或与之互动的人）在参考表格时将如何处理；“x表”或“xs表”

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

我认为使用单数是我们在大学里学到的。但同时，您可能会认为，与面向对象编程不同，表不是其记录的实例。

我想我现在倾向于单数，因为英语中的复数不规范。在德语中，由于没有一致的复数形式，情况更糟——有时，如果没有前面的指定冠词（der/die/das），你就无法判断一个单词是否为复数。无论如何，在汉语中没有复数形式。

我有同样的问题，在阅读了这里的所有答案后，我肯定会选择SINGULAR，原因如下：

原因1（概念）。你可以把装苹果的袋子想象成“苹果袋”，不管是装0个、1个还是100万个苹果，都是同一个袋子。表只是容器，表名必须描述它包含的内容，而不是它包含多少数据。此外，复数概念更多地是关于口语的一个（实际上是为了确定是否有一个或多个）。

原因2。（方便）。用单数名字比用复数名字更容易。对象可以有不规则的复数形式，也可以完全没有复数形式，但总是有单数形式（新闻等少数例外）。

顾客顺序使用者地位消息

原因3。（美学和秩序）。特别是在主细节场景中，这读起来更好，按名称排列更好，逻辑顺序更高（主细节优先，细节第二）：

1.订单2.订单详情

对比：

1.订单详情2.订单

原因4（简单）。把所有这些放在一起，表名、主键、关系、实体类。。。最好只知道一个名称（单数），而不是两个名称（单一类、复数表、单数字段、单数复数主细节…）

顾客客户.CustomerID客户地址公共类客户｛…｝从客户选择CustomerID=100

一旦你知道你是在和“客户”打交道，你就可以确定你会对所有的数据库交互需求使用同一个词。

原因5。（全球化）。世界越来越小，你可能有一个不同国籍的团队，但不是每个人都以英语为母语。对于非英语母语的程序员来说，想到“存储库”比想到“存储”更容易，或者想到“状态”而不是“状态”。使用单数名称可以减少因拼写错误导致的错误，不必思考“是孩子还是孩子？”，从而节省时间，从而提高生产力。

原因6。（为什么不呢？）。它甚至可以节省你的写作时间，节省你的磁盘空间，甚至让你的电脑键盘更耐用！

选择客户.CustomerName FROM Customer WHERE Customer.CustomerID=100选择Customers.CustomerName FROM Customers WHERE Customers.CustomerID=103

您已保存了3个字母、3个字节和3次额外的键盘点击：）

最后，你可以说出那些用保留名搞乱的名字，比如：

用户>LogiUser、AppUser、SystemUser、CMSUser，。。。

或者使用臭名昭著的方括号[User]

我不喜欢复数表名，因为英语中的一些名词是不可数的（水、汤、现金），或者当你使其可数时，其含义会发生变化（鸡vs鸡；肉vs鸟）。我也不喜欢使用表名或列名的缩写，因为这样做会给已经陡峭的学习曲线增加额外的斜率。

具有讽刺意味的是，我可能会将User作为一个例外，并将其称为User，因为User（Transac SQL），因为如果不需要的话，我也不喜欢在表周围使用括号。

我还喜欢将所有ID列命名为ID，而不是ChickenId或ChickenId（复数个家伙对此做什么？）。

这一切都是因为我对数据库系统没有适当的尊重，我只是在重新应用OO命名约定中的一个技巧，比如Java的习惯和懒惰。我希望有更好的IDE支持复杂的SQL。