两个网站都有不同的论文，我认为你只需要选择你的一方。就我个人而言，我更喜欢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

举个简单的例子：

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

vs.

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

后者中的SQL比前者听起来更奇怪。

我投票支持单数。

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

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

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

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

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

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

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

我个人更喜欢用复数来表示一个集合，这对我的关系思维来说“听起来”更好。

此时此刻，我正使用单数名称为我的公司定义一个数据模型，因为大多数工作人员都觉得它更舒服。有时候，你只需要让每个人的生活更轻松，而不是强加你的个人喜好。（这就是我在本主题中的结尾，以确认什么是命名表的“最佳实践”）

在阅读了这篇文章中的所有争论之后，我得出了一个结论：

不管每个人最喜欢的口味是什么，我都喜欢我的蜂蜜煎饼。但如果我为其他人做饭，我会尝试为他们提供他们喜欢的东西。