其他人已经给出了关于“标准”的相当不错的答案，但我想补充一下...是否有可能“用户”（或“用户”）实际上并不是表中所保存数据的完整描述？并不是说你应该对表名和特殊性太过疯狂，但或许像“Widget_Users”（其中“Widget”是你的应用程序或网站的名称）这样的名称更为合适。

我有同样的问题，在阅读了这里的所有答案之后，我肯定会选择SINGULAR，理由是：

原因1 (概念). 你可以将装着苹果的袋子称作“苹果袋”，不管里面是有0个，1个还是一百万个苹果，它都是同一个袋子。表格只是容器，表格的名称应该描述它包含了什么，而不是它包含了多少数据。此外，复数概念更多是关于口语语言的问题（实际上是用来确定是否有一个或更多个）。

原因2。（便利性）想出单数名称比想出复数名称更容易。物品可能有不规则的复数形式或根本没有复数形式，但始终有单数形式（除新闻等少数例外）。

• Customer
• Order
• User
• Status
• News

原因3。（美学和秩序）。特别是在主细节场景中，通过名称更好地读取，对齐得更好，有更合理的顺序（先主后细节）。

• 1.Order
• 2.OrderDetail

相较于：

• 1.OrderDetails
• 2.Orders

原因4（简单性）。把表名、主键、关系、实体类等全部放在一起，了解一个名称（单数）比了解两个名称（单数类、复数表、单数字段、单数-复数主从关系……）更好。

• Customer
• Customer.CustomerID
• CustomerAddress
• public Class Customer {...}
• SELECT FROM Customer WHERE CustomerID = 100

一旦您知道您正在处理的是“客户”，您可以确定您将在所有数据库交互需求中使用相同的词语。

第五个原因（全球化）。世界正在变得越来越小，您可能拥有来自不同国籍的团队，不是每个人都以英语为母语。对于非英语母语的程序员来说，想到“Repository”比想到“Repositories”或者想到“Status”比想到“Statuses”更容易。使用单数名称可以减少因疏忽打错字而造成的错误，节省时间，不用思考“Child还是Children？” 从而提高工作效率。

理由6。（为什么不呢？）它甚至可以节省您的写作时间，节省磁盘空间，甚至延长您电脑键盘的使用寿命！

• SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
• SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 103

你已经节省了3个字母，3个字节，还有3次不必要的按键:)

最后，您可以为那些破坏保留名称的人命名：

• User > LoginUser, AppUser, SystemUser, CMSUser,...

或使用臭名昭著的方括号[用户]。

我更喜欢使用不变化的名词，这在英语中恰好是单数形式。

把表格名字的數量變化會引起拼字問題（正如其他答案所示），但是選擇這樣做是因為表格通常包含多個行，這也在語義上有很多漏洞。如果我們考慮一個根據情況變化的名詞語言（大多數都是這樣），這更加明顯：

既然我们通常在处理行，为什么不将名称放入宾格？如果我们有一个我们写入比读取更多的表格，为什么不将名称放在与格中？这是一个关于某物的表格，为什么不使用属格？我们不会这样做，因为该表格被定义为一个抽象容器，无论其状态或用途如何都存在。在没有明确和绝对的语义理由的情况下屈折名词是胡言乱语。

使用未受变化的名词很简单、合乎逻辑、常规而且与语言无关。

如果您正在使用对象关系映射工具或将来会使用，我建议使用Singular。

一些工具（例如LLBLGen）可以自动纠正复数名称，例如将Users更正为User，而不改变表名本身。这很重要吗？因为当进行映射时，您希望它看起来像User.Name，而不是Users.Name，更糟糕的是，从我旧的数据库表命名tblUsers.strName中，这只会让代码更加混乱。

我的新准则是判断它转换成对象后会看起来如何。

我发现一个不符合我新命名规则的表是UsersInRoles。但总会有那么几个例外，就算是这种情况，也看起来还不错，就叫UsersInRoles.Username吧。

什么惯例要求表格使用单数名称？我一直以为是复数名称。

一个用户被添加到用户表中。

This site agrees:
http://vyaskn.tripod.com/object_naming.htm#Tables

This site disagrees (but I disagree with it):
http://justinsomnia.org/writings/naming_conventions.html

正如其他人所提到的：这些仅仅是指导方针。选择适合你和你的公司/项目的约定，并坚持下去。在单数和复数之间切换，或者有时缩写单词，有时不缩写，会更加令人恼火。

这个作为一个简单的例子怎么样？

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

对抗。

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

后者中的SQL听起来比前者更陌生。

我投票给单数。

我坚信，在实体关系图中，实体的名称应该采用单数形式，类似于类名称的单数形式。一旦被实例化，名称就反映其实例。因此，在数据库中，将实体制成表（实体或记录的集合）后是复数形式。实体“用户”变成表格“用户”（User变成Users）。我同意其他人的建议，也许“用户”这个名称可以改进成“员工”或其他更适用于场景的名称。

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

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

原因是什么？英语中有像“mouse ⇒ mice”和“sheep ⇒ sheep”这样的不规则复数形式。然后，如果我需要一个“集合”，我只需要使用“mouses”或“sheeps”，然后继续下去。

它真的能帮助众数脱颖而出，我可以轻松地编程确定事物的集合会是什么样子。

因此，我的规则是：一切都是单数，每一组东西都是带着附加s的单数形式。这对对象关系映射也有所帮助。

我的看法是，表名应该像Customers这样复数。

类名应该是单数，例如Customer，如果它映射到Customers表中的一行。

单数。我不相信任何与哪种逻辑最合理相关的争论 - 每个人都认为他自己的喜好是最合理的。不管你做什么都是一团糟，只需选择一种约定并坚持下去即可。我们正在尝试将一种具有高度不规则的语法和语义（正常口语和书面语言）映射到具有非常特定语义的高度规则化的SQL语法。

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

所以，AppUser关系告诉哪些实体是AppUsers。

AppUserGroup 关系告诉我哪些实体是AppUserGroups。

"AppUser_AppUserGroup" 关系告诉我如何关联 "AppUsers" 和 "AppUserGroups"。

AppUserGroup_AppUserGroup关系告诉我AppUserGroups和AppUserGroups之间的关系（即组成员所属的组）。

换句话说，当我考虑实体及其关系时，我认为关系是单数的，但当我考虑实体在集合或组中时，集合或组是复数的。

在我的代碼和數據庫架構中，我使用單數。在文本描述中，為了增加可讀性，我最終使用復數 - 然後使用字體等來區分表/關係名稱和復數。

我喜欢把它想象成凌乱但有系统性的，这样就能对我想要表达的关系始终生成系统地命名，而这对我来说非常重要。

我也会选择使用复数，对于上述的用户难题，我们采用方括号标记的方法。

我们这样做是为了在数据库架构和应用程序架构之间提供统一性，同时也要理解Users表是User值的集合，就像代码构件中的Users集合是User对象的集合一样。

让我们的数据团队和开发人员说着相同的概念语言（尽管不总是相同的对象名称），这样更容易在他们之间传达想法。

我个人更喜欢使用复数名称来代表一组，因为这样对于我的关系思维来说“听起来”更好。

At this exact moment i am using singular names to define a data model for my company, because most of the people at work feel more confortable with it. Sometimes you just have to make life easier to everyone instead of imposing your personal preferences. (that s how i ended up in this thread, to get a confirmation on what should be the "best practice" for naming tables)

在阅读了这个帖子中所有的争论后，我得出了一个结论：

我喜欢在我的煎饼上加蜂蜜，无论别人最喜欢的口味是什么。但是，如果我为其他人做饭，我会尽力为他们提供他们喜欢的食物。

我一直认为使用复数表名是流行惯例。直到现在，我一直使用复数。

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

一张汽车表格会有名为汽车的表名，每一行都是一辆车。我承认在table.field的方式下指定表格和字段是最佳实践，并且拥有单数表格名称更易读。然而在以下两个例子中，前者更有意义：

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

老实说，我会重新考虑我的立场，并会依靠我正在开发的组织实际使用的惯例。然而，对于我的个人惯例，我认为我会坚持使用复数表名。在我看来，这更有道理。

单数。我会将包含一堆用户行表示对象的数组称为用户(users)，但数据表是用户表。我认为将数据表视为仅是其包含的行集是错误的；数据表是元数据，而行集与数据表呈分层附加关系，而不是数据表本身。

我一直使用ORM，当然，使用复数表名编写的ORM代码看起来很愚蠢。

I don t like plural table names because some nouns in English are not countable (water, soup, cash) or the meaning changes when you make it countable (chicken vs a chicken; meat vs bird). I also dislike using abbreviations for table name or column name because doing so adds extra slope to the already steep learning curve.

具有讽刺意味的是，由于USER（Transac-SQL），我可能会将User作为异常情况并将其称为Users，因为如果不是必须的，我也不喜欢在表周围使用括号。

我也喜欢将所有ID列命名为Id，而不是ChickenId或ChickensId（复数的处理怎么办？）。

所有这一切都是因为我对数据库系统缺乏适当的尊重，我只是因为习惯和懒惰而重新应用了基于面向对象的命名约定（如 Java）。我希望有更好的 IDE 支持复杂的 SQL。

我们采用相似的标准，编写脚本时要求在名称周围加上[ ] ，并在适当的情况下使用模式限定符-主要是为了防止SQL语法未来名称被抓取。

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

这在过去拯救了我们的灵魂 - 我们的一些数据库系统运行了超过10年，从SQL 6.0到SQL 2005 - 超出了它们预期的使用寿命。

如果我们查看由Microsoft分配的MS SQL Server系统表的名称，它们是复数。

The Oracle s system tables are named in singular. Although a few of them are plural. Oracle recommends plural for user-defined table names. That doesn t make much sense that they recommend one thing and follow another. That the architects at these two software giants have named their tables using different conventions, doesn t make much sense either... After all, what are these guys ... PhD s?

我记得在学术界中，建议是单数。

例如，当我们说：

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference =  ABC123 

可能是因为每个 ID 都是从特定的单行中选择的吧……？

桌子：复数形式

用户表中列出了多个用户。

模特：单数

可以从用户表中选择一个唯一的用户。

控制器：复数形式

http://myapp.com/users 会列出多个用户。

这是我的看法。

服务器本身的系统表/视图（例如SYSCAT.TABLES、dbo.sysindexes、ALL_TABLES、information_schema.columns等）几乎总是复数形式。为了保持一致性，我想我会遵循它们的做法。

我喜欢单数表名，因为它们使我使用CASE语法的ER图更易于阅读，但是通过阅读这些回复，我感觉它从来没有很成功过？我个人很喜欢它。当你使用单数表名，为你的关系添加动作动词并为每个关系形成好的句子时，你的模型可以变得多么可读，这里有一个带有示例的良好概述。对于一个20个表的数据库来说，这有点过度但是如果你有一个有数百个表和复杂设计的数据库，没有好的可读图表，你的开发人员如何理解它？

将此翻译成中文：http://www.aisintl.com/case/method.html

至于为表格和视图添加前缀，我非常讨厌那种做法。在给他们可能有害信息之前不给对方任何信息。任何浏览数据库对象的人都能很容易地区分出表格和视图，但如果我有一个名为tblUsers的表在将来的某个时候由于某种原因决定重新构造为两个表格，通过一个视图合并它们以避免破坏旧代码，现在我的视图名为tblUsers。此时我只剩下两个不太吸引人的选择，要么留下具有tbl前缀的视图，这可能会使一些开发人员感到困惑，要么强制要求另一层（中间层或应用）重写代码以引用我的新结构或命名视图为viewUsers。在我看来，这抵消了视图的很大价值。

我曾经在用户表中使用了“Dude”一词——它具有相同少量的字符，不会与关键词冲突，但仍然可以表示一般人。如果我不担心可能会查看代码的保守人士，我就会一直保持这种方式。

我一直使用单数，只是因为这是我学过的方式。然而，最近创建新模式时，我第一次积极决定维持这个约定，只是因为……它更短。对每个表名添加“s”的结尾对我来说是毫无用处的，就像在每个表前添加“tbl_”一样。

这可能有些重复，但我建议谨慎行事。不一定是给表重命名是一件坏事，但是标准化就是标准——这个数据库可能已经“标准化”了，虽然很糟糕:)——鉴于这个数据库已经存在，而且很可能它不仅由两个表组成，所以我建议一致性是更好的目标。

除非您能够标准化整个数据库，或者至少计划朝着这个目标努力，否则我怀疑表名只是冰山一角，全力完成当前任务，忍受糟糕名称的对象带来的痛苦可能是您最好的选择。

实际上，一致有时候是最好的标准... :)

我的意见

正如其他人在此提到的，约定应该是一种增加易用性和可读性的工具，而不是对开发人员进行折磨的枷锁或棍棒。

话虽如此，我的个人偏好是对表和列使用单数名称。这可能来自于我的编程背景。类名通常是单数，除非它们是某种集合。在我看来，我在存储或读取所讨论的表中的单个记录，因此单数对我来说很有意义。

这种做法还允许我保留复数表名，用于存储对象之间的多对多关系。

我尽量避免在我的数据表和列名称中使用保留字。在这个问题的情况下，为了避免需要封装使用保留字“User”的表，采用与“用户”单数约定相反的方式更有意义。

我喜欢有限地使用前缀（tbl代表表名，sp_代表存储过程名称等），尽管许多人认为这会增加混乱。我也更喜欢驼峰命名法而不是下划线，因为我总是在键入名称时按 + 键而不是 _ 键。许多人持不同意见。

这是另一个好的命名约定指南链接：http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

记住，在您的规定中最重要的因素是它对与相关数据库交互的人有意义。在命名规范方面，没有“一环统治它们所有”。

可能的替代方案：

• Rename the table SystemUser
• Use brackets
• Keep the plural table names.

在我看来，使用括号在技术上是最安全的方法，尽管有点繁琐。在我看来，这是有得有失的，你的解决方案实际上只取决于个人或团队的偏好。

我的想法取决于语义，取决于你如何定义你的容器。例如，“一袋苹果”或仅仅是“苹果”或“苹果袋”或“苹果”。

Example: a "college" table can contain 0 or more colleges a table of "colleges" can contain 0 or more collegues

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

我的结论是，任何一种方式都可以，但你必须定义在提到表格时你（或与之互动的人）会如何处理; 是否为“x的表”或“表格中的x”。

我认为在大学里我们学习使用单数。但同时，你可以争辩说，与面向对象编程不同，表不是其记录的实例。

我觉得目前我倾向于使用单数，这是因为英语中有很多不规则的复数形式。在德语中，由于没有一致的复数形式，情况甚至更糟 - 有时候你必须在它前面加定冠词（der/die/das），才能确定一个单词是复数还是单数。而在中国语言中，根本没有复数形式。

我一直认为那是愚蠢的约定。我使用复数表名。

我相信这项政策的理由是，它使ORM代码生成器更容易生产对象和集合类，因为从单数名词产生复数名词比反过来要容易得多。

我的表格名称只使用那些单复数拼写相同的名词。

moose fish deer aircraft you pants shorts eyeglasses scissors species offspring

我没有在以前的回答中清楚地表述过这一点。许多程序员在处理表格时没有明确的定义。我们通常用“记录”或“行”这样的术语直觉地进行沟通。然而，除了反规范化关系的一些例外情况，表格通常被设计为非关键属性和关键属性之间的关系构成了一个集合论函数。

一个函数可以被定义为两个集合的叉积的一个子集，在这个映射中，键集合的每个元素 最多出现一次。因此，从这个角度出发产生的术语倾向于是单数的。在其他涉及函数的数学和计算理论中（例如代数和λ演算），可以看到相同的单数（或至少非复数）约定。