表命名困境：单数名与复数名

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

用户被添加到用户表中。

本网站同意：
http://vyaskn.tripod.com/object_naming.htm#Tables

这个网站不同意（但我不同意）：
http://justinsomnia.org/writings/naming_conventions.html

正如其他人提到的：这些只是指导方针。选择一个适合你和你的公司/项目的惯例，并坚持下去。在单数和复数之间切换，有时是缩写词，有时不是更让人恼火。

可能的替代方案：

• 重命名表SystemUser
• 使用括号
• 保留复数表名。

国际海事组织使用括号在技术上是最安全的方法，尽管它有点麻烦。在国际海事组织看来，这是一个6，另一个6，你的解决方案实际上归结为个人/团队偏好。

我一直认为这是一个愚蠢的惯例。我使用复数表名。

（我相信该策略背后的理由是它使ORM代码生成器更容易生成对象和集合类，因为从单数名称生成复数名称比从单数名称生成复数名称更容易）

指导方针确实存在。它不是“一成不变”的，这就是为什么你可以选择忽略它们。

我想说，使用复数表名在逻辑上更直观。表毕竟是实体的集合。除了提到的其他替代方案，我通常会在表名上看到前缀…

• tblUser
• tblthis
• tblIt
• tblthe其他

我并不是说这是要走的路，我也看到在表名中使用了很多我讨厌的空格。我甚至遇到过带有白痴字符的字段名，比如？好像说这个字段回答了一个问题。

这可能有点多余，但我建议要谨慎。重命名表不一定是坏事，但标准化就是这样；一个标准-这个数据库可能已经是“标准化的”，无论多么糟糕 :) -- 我建议一致性是一个更好的目标，因为这个数据库已经存在，并且可能不止由两个表组成。

除非您可以标准化整个数据库，或者至少计划为此而努力，否则我怀疑表名只是冰山一角，专注于手头的任务，忍受命名不佳的对象的痛苦，可能符合您的最佳利益

实际的一致性有时是最好的标准…：）

my2美分---

没有要求表名为单数的“约定”。

例如，我们在评级过程使用的数据库上有一个名为“REJECTS”的表，其中包含从程序的一次运行中拒绝的记录，我认为没有任何理由不使用复数表（将其命名为“REJECT”会很有趣，或者太乐观了）。

关于另一个问题（引号），它取决于SQL方言。Oracle不需要在表名周围加上引号。

正如其他人在这里提到的，约定应该是增加易用性和易读性的工具。而不是折磨开发人员的枷锁或俱乐部。

也就是说，我个人的偏好是对表和列都使用单数名称。这可能来自我的编程背景。类名通常是单数的，除非它们是某种集合。在我的脑海中，我正在存储或读取有关表中的单个记录，所以单数对我来说是有意义的。

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

我也尽量避免在表名和列名中使用保留字。在这里讨论的情况下，与用户的单数约定背道而驰更有意义，以避免需要封装使用用户保留字的表。

我喜欢以有限的方式使用前缀（tbl用于表名称，sp_用于过程名称等），尽管许多人认为这会增加混乱。我也更喜欢CamelBack名称而不是下划线，因为我总是在键入名称时点击+而不是_。许多其他人不同意。

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

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

我们运行类似的标准，在编写脚本时，我们要求[]围绕名称，并在适当的模式限定符-主要是通过SQL语法对冲您对未来名称抓取的赌注。

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

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

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

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

我也喜欢将所有ID列命名为Id，而不是ChickenId或ChickensId（复数人对此做了什么？）。

所有这一切都是因为我对数据库系统没有足够的尊重，我只是出于习惯和懒惰，从像Java这样的OO命名约定中重新应用一招小马知识。我希望有更好的IDE支持复杂的SQL。

就“标准”而言，其他人给出了很好的答案，但我只是想补充一下……“用户”（或“用户”）实际上可能不是对表中数据的完整描述吗？不是说你应该对表名和特异性太疯狂，但也许像“Widget_Users”（其中“Widget”是你的应用程序或网站的名称）这样的东西会更合适。

我通过将表命名为“员工”（实际上是“员工”）来解决同样的问题。我尽量远离任何可能使用保留字的冲突。即使是“用户”对我来说也不舒服。

如果您使用某些框架，如Zend Framework（PHP），那么对于表类使用复数，对于行类使用单数是明智的。

因此，假设您创建了一个表对象$user=新用户（）并将行类声明为User，您也可以调用new User（）。

现在，如果您对表名使用单数，您将不得不执行诸如new UserTable（）之类的操作，其中的行是new UserRow（）。

如果你去，会有麻烦，但如果你留下来，它会加倍。

我宁愿违背一些所谓的非复数命名约定，也不愿用可能是保留字的东西来命名我的表。

服务器本身的系统tables/views（SYSCAT.TABLES、dbo.sysindexes、ALL_TABLES、information_schema.columns等）几乎总是复数。我想为了一致性，我会跟随他们的领导。

我也会选择复数，在前面提到的用户困境中，我们确实采取了方括号方法。

我们这样做是为了提供数据库体系结构和应用程序体系结构之间的一致性，其基本理解是用户表是用户值的集合，就像代码工件中的用户集合是用户对象的集合一样。

让我们的数据团队和我们的开发人员使用相同的概念语言（尽管并不总是相同的对象名称）可以更容易地在他们之间传达想法。

如果您使用对象关系映射工具或将来使用，我建议单数。

像LLBLGen这样的一些工具可以自动更正复数名称，例如用户到用户，而无需更改表名本身。为什么这很重要？因为当它映射时，您希望它看起来像User. Name而不是User. Name，或者更糟，因为我的一些旧数据库表命名tblUsers.strName，这在代码中只是令人困惑。

我的新经验法则是判断它被转换为对象后的外观。

我发现一个不适合我使用的新命名的表是UsersInRoles。但总会有少数例外，即使在这种情况下，它看起来像UsersInRoles. Username一样好。

对于表名和任何编程实体，我坚持使用奇异。

为什么？因为英语中有不规则复数，比如老鼠，老鼠和羊羊。然后，如果我需要收藏，我就用老鼠或绵羊，然后继续。

它确实有助于多元化脱颖而出，我可以轻松地以编程方式确定事物的集合会是什么样子。

所以，我的规则是：一切都是奇异的，每个事物的集合都是奇异的，附加了的。也有助于ORM。

我坚信在实体关系图中，实体应该用单数名称反映，类似于类名是单数。一旦实例化，名称就反映了它的实例。因此，对于数据库，实体制成表（实体或记录的集合）时是复数的。实体、用户被制成表用户。我同意其他人的建议，也许用户可以改进为员工或更适用于你的场景。

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

单数。我将包含一堆用户行表示对象的数组称为“用户”，但表是“用户表”。认为表只是它包含的行的集合是错误的，IMO；表是元数据，行的集合在层次上附加到表上，它不是表本身。

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

我是单数表名的粉丝，因为它们使我使用CASE语法的ER图更易于阅读，但是通过阅读这些回复，我感觉它从来没有很好地流行起来？我个人喜欢它。有一个很好的概述，上面有例子说明当你使用单数表名、在关系中添加动作动词并为每个关系形成好句子时，你的模型的可读性。对于一个20个表的数据库来说，这有点矫枉过正，但是如果你有一个包含数百个表和复杂设计的数据库，如果没有一个好的可读图，你的开发人员将如何理解它？

http://www.aisintl.com/case/method.html

至于给表和视图加上前缀，我非常讨厌这种做法。在给一个人可能的坏信息之前，根本不给他们任何信息。任何在数据库中浏览对象的人都可以很容易地分辨出一个表和一个视图，但是如果我有一个名为tbl用户的表，出于某种原因，我决定在未来重组为两个表，一个视图将它们统一起来以防止破坏旧代码，我现在有一个名为tbl用户的视图。在这一点上，我留下了两个不吸引人的选择，留下一个以tbl前缀命名的视图，这可能会让一些开发人员感到困惑，或者强制另一个层，中间层或应用程序重写以引用我的新结构或名称view用户。这否定了很大一部分观点的价值IMHO。

我将给出我的意见，为什么我使用奇异名称。

例如，我需要从用户那里获取所有字段：

-- Select every fields from 'user' tableSELECT * FROM user

我需要21岁的用户名：

-- Select every fields from 'user' table which have 21 years oldSELECT * FROM user WHERE age = '21'

当然，复数的方式也可以用同样的方式，但是为了让我的大脑阅读，我真的认为这是正确的方式。

这是一个简单的例子：

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

vs.

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

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

我投票奇异。

IMHO，表名应该像客户一样复数。

如果类名映射到客户表中的一行，则类名应为单数，如客户。

我总是使用单数表名，但如前所述，最重要的是保持一致，并对所有名称使用相同的形式。

我不喜欢复数表名的地方是组合名称会变得非常奇怪。例如，如果您有一个名为Users的表，并且您想为用户存储属性，这将导致一个名为UsersProperties的表…

表格：复数

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

型号：单数

可以从用户表中选择单个用户。

控制器：复数

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

这是我对它的看法，无论如何。

我认为使用单数是我们在大学里学到的，但与此同时，你认为与面向对象程序设计不同，表不是其记录的实例。

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

实际上，我一直认为使用复数表名是流行的惯例。到目前为止，我一直使用复数。

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

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

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

老实说，我会重新考虑我在这个问题上的立场，我会依赖我正在开发的组织使用的实际惯例。然而，我认为，就我个人的惯例而言，我会坚持使用复数表名。对我来说，这更有意义。

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

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

既然我们通常对行做一些事情，为什么不把名称放在宾格中呢？如果我们有一个表，我们写的比读的多，为什么不把名称放在与格中呢？这是一个表的的东西，为什么不使用属格呢？我们不会这样做，因为表被定义为一个抽象容器，无论它的状态或用法如何，它都存在。没有精确和绝对的语义原因来表达名词是胡言乱语。

使用未屈折的名词是简单的，合乎逻辑的，规则的和语言无关的。

我一直使用单数，只是因为这是我被教导的。然而，最近在创建一个新模式时，这是很长一段时间以来的第一次，我积极决定保持这个约定，仅仅是因为……它更短。在每个表名的末尾添加一个's'对我来说似乎和在每个表名前面添加'tbl_'一样没用。

单数。我不相信任何涉及哪个最合乎逻辑的争论——每个人都认为自己的偏好最合乎逻辑。无论你做什么，都是一团糟，只要选择一个惯例并坚持下去。我们试图将一种语法和语义学高度不规则的语言（正常的口语和书面语）映射到具有非常特定语义学的高度规则（SQL）语法。

我的主要论点是，我不认为桌子是一组，而是关系。

因此，AppUser关系告诉哪些实体是AppUsers。

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

AppUser_AppUserGroup关系告诉我AppUsers和AppUserGroups是如何相关的。

AppUserGroup_AppUserGroup关系告诉我AppUserGroups和AppUserGroups是如何相关的（即组的组成员）。

换句话说，当我想到实体以及它们之间的关系时，我想到的是单数关系，但当然，当我想到集合或集合中的实体时，集合或集合是复数。

然后，在我的代码和数据库模式中，我使用单数。在文本描述中，我最终使用复数来增加易读性-然后使用字体等来区分表/关系名称和复数s。

我喜欢把它看作是凌乱的，但系统的——这样，我想表达的关系总是有一个系统生成的名字，这对我来说非常重要。

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

原因1（概念）。你可以把包含苹果的袋子想象成“AppleBag”，无论包含0个、1个还是100万个苹果，它总是同一个袋子。表就是这样，容器，表名称必须描述它包含什么，而不是它包含多少数据。此外，复数概念更多的是关于口语one（实际上是确定是否有一个或多个）。

原因2.（方便）。单数名称比复数名称更容易出现。对象可以有不规则的复数或根本不复数，但总是有一个单数（像News这样的少数例外）。

• 客户
• 订单
• 用户
• 状态
• 新闻

原因3.（美学和秩序）。特别是在主细节场景中，这读起来更好，按名称对齐更好，并且有更多的逻辑顺序（主第一，细节第二）：

• 1.命令
• 订单详情

对比：

• 订单详情
• 2.命令

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

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

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

原因5.（全球化）。世界越来越小，可能有一个不同国籍的团队，也不是每个人的母语都是英语。对于一个英语非母语的程序员来说，想到“Repostory”会比想到“Repositories”更容易，想到“Status”会更容易。名称使用单数形式可以减少错别字导致的错误，不用去想“是Children还是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，…

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

我在语义学上的看法取决于你如何定义你的容器。例如，“一袋苹果”或简称“苹果”或“苹果袋”或“苹果”。

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

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

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

TABLE名称是表结构的一个定义。VIEW或QUERY名称是（一个或多个）表的视图或查询的一个定义。表、视图或查询可能包含以下内容之一：

0条记录1条记录很多记录

你究竟为什么要在单个对象名称的末尾加上's'？你想通过把这个's'放在对象名称的末尾来表示什么？

如果要区分，请添加“_tbl”。视图是“_vew”（不是愚蠢的“_v”约定）。

最少3个字符后缀-停止这个讨论死了。

表是一个DB对象-与任何其他对象没有什么不同。

3个字符的保存除了含义的清晰度之外没有任何节省。

红色；-）

我只对拼写相同的表名使用名词，无论是单数还是复数：

驼鹿鱼鹿飞机你裤子短裤眼镜剪刀物种后代

如果我们查看MS SQL Server's系统表，它们由Microsoft分配的名称在plural中。

Oracle的系统表以singular命名。尽管其中一些是复数。Oracle建议用户定义的表名使用复数。他们推荐一件事并遵循另一件事并没有多大意义。这两个软件巨头的架构师使用不同的约定来命名他们的表，也没有多大意义……毕竟，这些家伙是什么……博士？

我确实记得在学术界，这个建议是独一无二的。

例如，当我们说：

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

也许b/c每个ID是从特定的单行中选择的…？

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

我曾经在User表中使用过“伙计”——同样的短字符数，与关键字没有冲突，仍然是对通用人类的引用。如果我不担心可能看到代码的闷头，我会保持这种方式。

在前面的回答中，我没有看到这一点被清晰地表达出来。许多程序员在处理表时没有正式的定义。我们经常直观地用“记录”或“行”来交流。然而，除了一些非规范化关系的例外，表通常被设计成非键属性和键之间的关系构成一个集合理论函数。

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

我个人更喜欢用复数来表示一个集合，它只是“听起来”更适合我的关系思维。

此时此刻，我正在使用单数名称为我的公司定义一个数据模型，因为大多数工作中的人对它感到更舒服。有时你只需要让每个人的生活更轻松，而不是强加你的个人偏好。（这就是我在这个线程中结束的方式，以确认命名表的“最佳实践”应该是什么）

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

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

在寻找良好的命名规范时，出现了以下混淆，我应该命名：

1）根据表所包含的内容一个用户表。它总是复数的。所以，用户

2）根据“强”记录所持有的例如：用户表中的一条记录将是一个用户。SO，用户。

现在，问题主要users_roles。案例1：根据第一个命名约定，users_roles这个名字意味着什么，用户和他们的角色。

案例2：根据第二个命名约定，user_role这个名字意味着什么，用户和他的角色。

好的命名约定是给一个实体关系的额外概念，特别是当存储了多对多关系时

在这里，根据场景，我们应该识别为信息集。

在用户表中，形成的所有集合都是唯一的用户。在角色表中，形成的所有集合都是唯一的角色。在用户和角色关系表中，可以用不同的角色组成用户集，这给出了存储的1-多个关系的想法。

I would prefer,Users table => userRoles table => roleusers role relationship table => user_roles

这两个网站上有不同的论文，我认为你只需要选择你的立场。就我个人而言，我更喜欢Plurar用于表命名，当然单数用于列命名。

我喜欢你怎么读这个：

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

这些听起来不错吧？

无论如何，还要看看W3School使用的命名约定：