复数与单数表名

由你决定。不过要保持一致。

就我个人而言，我更喜欢基于每个 *row" 存储的单数：订单、产品、用户、项目等。

这与我使用单一实体/类型的建模（通过对象角色建模）相匹配。

编辑：

一个原因是，当您有链接表时，复数会失败：
Orders,Products会给出OrderProductsor OrdersProducts。听起来都不对

或历史表（当然您可以为此使用模式）：
Orders->OrdersHistory或（否！）OrdersHistories？不会Order->OrderHistory更好吗？

关于单数和复数表名，这个主题似乎是有争议的，但它不应该是。

虽然表是多条记录的集合，但表是以它所包含的一种记录类型的定义命名的。如果允许表具有与其包含的记录类型不同的名称，则可以为该表指定一个复数名称，例如，您可以拥有一个包含多个 Employee 记录的Employees 表。但是 SQL 的设计者并没有为表和记录类型提供单独的名称。

如果记录类型的名称（以及表名的扩展名）保持单数，那么对于使用数据的面向对象程序来说，事情会更合乎逻辑，因为它将与您用来描述一条记录的类的名称相对应.

如果您想在程序中识别一个集合，您可以使用复数形式，或者更好的是，使用适当的修饰符，例如 EmployeeList 或 EmployeeArray。

对于自动代码生成和具有不同语言背景或对程序中形成复数的想法的程序员来说，不规则复数也存在问题。

英语不是一种好的和适当的编程语言，并且试图使数据库和程序语句符合英语，因为阅读其中一个语句听起来更好是错误的。

“订单”是保留字。“命令”不是

“用户”是保留字。“用户”不是

“会话”是保留字。“会话”不是

“结果”是保留字。“结果”不是

“相对”是保留字。“亲戚”不是

...

这些似乎是可能出现在业务线数据库中的常用词。复数词作为关键词似乎不如单数词常见。因此，使用复数表名以避免与 SQL 关键字冲突可能是有益的。

就像@gbn 的回答一样，我认为这主要是一个偏好问题，就像他一样，我建议您做出任何选择，将其应用到任何地方（至少在那个数据库中）。一致性是值得的。

然而，我的偏好是复数在SELECT陈述中听起来更好：

SELECT Id, Name, Status 
FROM   Persons
WHERE  Status <> 5  --5 meaning deleted

我的意思是在这种情况下，至少桌子上有几个人，其中几个人被退回给客户。

在从事编程工作多年后，我得出结论，多元化是不必要的复杂化。我的观点是，根据 KISS 哲学，出于时间和效率的原因，程序员应该为所有问题争取最懒惰和最简单的解决方案。因此，单数可以减少所有场景中所需的工作量。

我相信 SQL 表应该有复数名称。它只是读起来好多了。

账簿记录表应称为账簿。ORM 应该使用相同的约定。Books 对象是一个集合，负责管理 Books 表中的所有记录。Book 对象主持单个记录。

这使得编码更加自然。

select name, publication_date from books where publication_date > '2000-01-01';

books = Books()
for book in books.get("publication_date >= '2000-01-01'"):
    print book.name

这是一件非常私人的事情。我使用单数形式已经 30 年了。但我明白为什么人们喜欢复数形式。书籍 - 作者很有趣，因为我认为书籍作者没有错。一本书可以有一个或多个作者。作者可能已经写了一本或多本书（例如合着）。它还取决于您如何处理由不止一位作者撰写的书籍。我同意其他答案；选择一个并保持一致。关于保留字问题。我认为想出解决方法名称并不难。用户 -> app_user ，会话 -> app_session，订单 -> customer_order

我们从不同的角度看待事物，我认为这两个阵营是通过以下方式确定的：

单数（“用户”）
将表名与其表示容器的事实相关联的人，该容器可以包含多行。

所以“用户容器”可以包含多行。

复数（“用户”）
不将表名与其代表容器的事实联系起来的人。他们当然知道这是一个容器，但名称中并没有。

例如
，“鸡蛋盒”中可以有多个鸡蛋，但这很明显，因为名称中包含容器引用，从而为多个鸡蛋提供了可能性。但是，对于单数表名“user”，名称中不存在容器引用。例如，“user_container”对于喜欢复数名称的人来说可能是可以接受的。

我认为这也是因为多年来复数是普遍的做法，并且在大多数在线教材中。

综上所述，我认为从技术上讲，单数更准确，因为我们正在命名单个容器，并且容器可以包含多行（或单行）。
对人们来说，这似乎是错误的，因为他们在心理上将表名链接到内容（多行需要一个复数名称），而不是在心理上将命名容器链接到内容（一个容器允许多个）。

与往常一样，虽然通常没有对与错，但更多的是关于适合场景的内容，重要的是与您选择的任何内容保持一致。

如果你只是在做这个项目，并且没有真正的理由去做任何你认为最好的事情，或者只是偏好。在开发团队中应用相同的方法，然后做出一致的决定。

关于“复数”的争论似乎主要是关于语法正确，虽然我们在编程中具有一定程度的语法，但它与实际的英语语言本身并不相同。

“复数”名称听起来是正确的，因为这些表被认为是多个事物，“用户”等。如果您与 40 个站点用户进行商务会议，您会将他们称为“我们所有的网络用户” ”。但是你的表中实际上并没有“网络用户”，它只是数据，所以把它想象成“网络用户数据”。你不会在你的表名上加上“数据”这个词，但这就是它的本质，一组与“webUser”相关的具有一行或多行的数据。

想象一家农业企业必须存储有关其动物的数据。他们有一张名为“奶牛”的桌子，将开始与“羊”交易。

• 该表是否应该是“绵羊”并与所有其他复数名称（如“奶牛”）打破一致性？
• 表格应该是不正确的英文“sheeps”吗？甚至不是一个字

业务进一步发展，现在他们交易鹿和鳕鱼……

那么我们是否有不一致的地方，这很烦人：

• 奶牛
• 羊
• 猪
• 鹿
• 鳕鱼

或一致性，但使用无效的单词会激怒大多数人阅读它们：

• 奶牛
• 羊
• 猪
• 鹿
• 鳕鱼

“鳕鱼”？来吧。

当您有多个表相互关联时，它也会中断。您要么继续复数以保持一致性，并且表名听起来很糟糕，要么破坏一致性：

• 用户
• usersHolidays 或 userHolidays
• usersHolidaysRemainings 或 userHolidaysRemainings 或...????

对比

• 用户
• 用户假期
• userHolidayRemaining