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

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

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

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

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

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

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

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

两个网站都有不同的论文，我认为你只需要选择你的一方。就我个人而言，我更喜欢Plular来命名表，当然，单数来命名列。

我喜欢你怎么读这个：

SELECT CustomerName FROM Customers WHERE CustomerID = 100;

的确，我们有OOP，这很好，但大多数人仍然使用关系数据库，而不是对象数据库。关系数据库不需要遵循OOP概念。

另一个例子是，您有一个表Teams，它保存了TeamID、TeamColor和PlayerID，并且对于一定数量的PlayerID将具有相同的TeamID和TeamColor。。。

该球员属于哪支球队？

SELECT * FROM Teams WHERE PlayerID = X

X队的所有球员？

SELECT * FROM Players INNER JOIN Teams ON Players.PlayerID = Teams.PlayerID WHERE Teams.TeamID = X

你觉得这一切都好吗？

无论如何，还可以看看W3Schools使用的命名约定：

http://www.w3schools.com/sql/sql_join_inner.asp

我们运行类似的标准，在编写脚本时，我们要求[]围绕名称，并在适当的情况下使用模式限定符-主要是为了防止SQL语法将来夺取名称。

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

这在过去拯救了我们的灵魂——我们的一些数据库系统从SQL 6.0到SQL 2005已经运行了10多年——远远超过了预期寿命。