表命名困境：单数名称与复数名称 [已关闭]

什么约定要求表具有单数名称？我一直以为是复数名称。

用户将添加到“用户”（Users） 表格中。

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

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

---

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

可能的替代方案：

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

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

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

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

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

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

• tbl用户
• tbl这个
• tbl那
• tblThe其他

我并不是说这是要走的路，我也看到我讨厌的表名中经常使用空格。我什至遇到过带有愚蠢字符的字段名称，例如？好像在说这个领域回答了一个问题。

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

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

实用的一致性有时是最好的标准...... :)

my2cents ---

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

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

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

正如其他人在这里提到的，约定应该成为增加易用性和可读性的工具。不是作为折磨开发人员的枷锁或棍棒。

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

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

我也尽量避免在表名和列名中保留字。在此所讨论的案例中，与 Users 的单数约定相反更有意义，以避免封装使用 User 保留字的表的需要。

我喜欢以有限的方式使用前缀（tbl 表示表名，sp_ 表示 proc 名等），尽管许多人认为这会增加混乱。我也更喜欢 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'

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

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

具有讽刺意味的是，我可能会因为 USER （Transac-SQL） 而破例并调用它，因为如果不需要的话，我也不喜欢在表周围使用括号。UserUsers

我还喜欢将所有 ID 列命名为 ，而不是 or（复数人对此有何看法？IdChickenIdChickensId

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

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

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

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

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

现在，如果您使用单数作为表名，则必须执行类似 new UserTable（） 的操作，该行为 new UserRow（）。在我看来，这比仅仅为表设置一个对象 Users（） 和为行设置一个对象 User（） 对象更笨拙。

如果你去，会有麻烦，但如果你留下来，那将是双倍的。

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

服务器本身的系统（、、、等）几乎总是复数的。我想为了保持一致性，我会跟随他们的脚步。tables/viewsSYSCAT.TABLESdbo.sysindexesALL_TABLESinformation_schema.columns

我也会选择复数形式，对于前面提到的用户困境，我们确实采用了方括号方法。

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

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

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

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

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

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

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

原因是什么？事实上，英语中有不规则的复数形式，如老鼠⇒老鼠和绵羊⇒绵羊。然后，如果我需要收藏，我只需使用鼠标或绵羊，然后继续前进。

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

所以，我的规则是：一切都是单数的，每个事物的集合都是单数的，并附加了一个 s。对 ORM 也有帮助。

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

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

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

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

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

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

至于为表格和视图添加前缀，我绝对讨厌这种做法。在向一个人提供可能不好的信息之前，他们根本没有提供任何信息。任何浏览数据库对象的人都可以很容易地从视图中分辨出一个表，但是如果我有一个名为 tblUsers 的表，出于某种原因，我决定将来重组为两个表，并统一它们以防止破坏旧代码，我现在有一个名为 tblUsers 的视图。在这一点上，我只剩下两个不吸引人的选项，留下一个以 tbl 前缀命名的视图，这可能会使一些开发人员感到困惑，或者强制重写另一层，无论是中间层还是应用程序，以引用我的新结构或名称 viewUsers。恕我直言，这否定了视图的很大一部分价值。

我只想说我为什么使用单数名称。

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

-- Select every fields from 'user' table
SELECT * FROM user

我需要 21 岁的用户姓名：

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

当然，复数方式也可以用同样的方式使用，但对于我的大脑来说，我真的认为这是正确的方法。

举个简单的例子怎么样：

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

与。

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

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

我投票给单数。

恕我直言，表名应该是复数形式，如 Customers。

如果类名映射到 Customers 表中的行，则类名应为单数，如 Customer。

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

我不喜欢复数表名的一点是，组合名称可能会变得很奇怪。例如，如果您有一个名为 的表，并且想要存储用户的属性，这将产生一个名为 ...UsersUsersProperties

表：复数

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

模型：单数

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

控制器：复数

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

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

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

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

实际上，我一直认为使用复数表名是流行的惯例。在此之前，我一直使用复数形式。

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

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

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

老实说，我将重新考虑我在这个问题上的立场，我将依赖我正在开发的组织使用的实际约定。但是，我认为出于我个人的惯例，我将坚持使用复数表名。对我来说，这更有意义。

我更喜欢使用无屈折的名词，在英语中恰好是单数。

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

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

使用无屈折名词是简单的、合乎逻辑的、有规律的和独立于语言的。

我一直使用单数，因为这是我被教导的。然而，在最近创建一个新模式时，很长一段时间以来，我第一次主动决定保持这个约定，仅仅是因为......它更短。在我看来，在每个表名的末尾添加一个“s”就像在每个表名前面添加“tbl_”一样无用。

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

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

因此，该关系告诉哪些实体是 .AppUserAppUsers

这种关系告诉我哪些实体是AppUserGroupAppUserGroups

关系告诉我 和 是如何相关的。AppUser_AppUserGroupAppUsersAppUserGroups

这种关系告诉我如何和是相关的（即组的成员）。AppUserGroup_AppUserGroupAppUserGroupsAppUserGroups

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

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

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

我有同样的问题，在阅读了这里的所有答案后，我绝对会留在 SINGULAR，原因：

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

原因 2.（方便）。用单数名称比用复数名称更容易。对象可以有不规则的复数形式，也可以根本不是复数形式，但总是有一个单数形式（除了少数例外，如新闻）。

• 客户
• 次序
• 用户
• 地位
• 新闻

原因 3.（审美与秩序）。特别是在大纲-细节方案中，这读起来更好，按名称更好地对齐，并且具有更多的逻辑顺序（主控在前，细节在后）：

• 1.订单
• 2.订单明细

相比于：

• 1.订单详情
• 2.订单

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

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

一旦你知道你正在与“客户”打交道，你就可以确定你将使用同一个词来满足你所有的数据库交互需求。

原因 5.（全球化）。世界越来越小，你可能有一个不同国籍的团队，不是每个人都以英语为母语。对于非英语母语的程序员来说，更容易想到“存储库”而不是“存储库”，或者想到“状态”而不是“状态”。使用单数名称可以减少由拼写错误引起的错误，节省时间，不必考虑“是孩子还是孩子？”，从而提高生产力。

原因 6.（为什么不呢？它甚至可以节省您的写作时间，节省您的磁盘空间，甚至让您的电脑键盘使用寿命更长！

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

您已经保存了 3 个字母、3 个字节、3 次额外的键盘点击:)

最后，您可以命名那些与保留名称混淆的名称，例如：

• 用户> LoginUser、AppUser、SystemUser、CMSUser,...

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

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

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

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

我的结论是，两者都很好，但你必须定义你（或与之交互的人）在引用表格时将如何处理;“X 表”或“X 表”

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

0 条记录 1 条记录 许多记录。

你到底为什么要在单个对象名称的末尾加上一个“s”？ 通过将这个“s”放在对象名称的末尾，您想表示什么？

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

至少 3 个字符的后缀 - 这会阻止此讨论。

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

保存 3 个字符除了含义清晰之外什么也没保存。

红色 ;-）

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

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

如果我们查看系统表，它们由 Microsoft 分配的名称位于 .MS SQL Server'splural

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

我记得在学术界，这个建议是单一的。

例如，当我们说：

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

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

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

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

我在之前的任何答案中都没有清楚地看到这一点。许多程序员在使用表格时没有正式的定义。我们经常用“记录”或“行”来直观地进行交流。但是，除了非规范化关系的一些例外情况外，通常将表设计为使非键属性和键之间的关系构成集合理论函数。

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

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

此时此刻，我正在使用单数名称来为我的公司定义数据模型，因为大多数工作人员都对它感到更舒适。 有时，您只需要让每个人的生活更轻松，而不是强加您的个人喜好。 （这就是我最终进入这个线程的方式，以确认命名表的“最佳实践”）

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

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

在寻找好的命名方式时，会出现以下混淆，我应该命名：

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

2） 根据记录所包含的内容，例如：用户表中的记录将是一个用户。所以，用户。

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

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

好的命名约定是提供实体关系的额外概念，尤其是在存储多对多关系时。

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

在 users 表中，形成的所有集合都是唯一的用户。 在“角色”（Roles） 表格中，形成的所有集合都是唯一的角色。 在用户和角色关系表中，可以形成具有不同角色的用户集，从而给出存储的一对多关系的概念。

I would prefer,
Users table => user
Roles table => role
users 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

这一切对你来说听起来不错？

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

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