1647

学术界认为表名应该是它们存储属性的实体的单数。

我不喜欢任何需要在名称周围加上方括号的 T-SQL，但我已将一个Users表重命名为单数，永远判刑那些使用该表的人有时必须使用方括号。

我的直觉是保持单数更正确，但我的直觉也是括号表示不受欢迎的内容，例如列名中带有空格等。

我是该留下还是该离开？

4

41 回答 41

2037

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

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

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

  • 顾客
  • 命令
  • 用户
  • 地位
  • 消息

原因 3。（审美和秩序）。特别是在 master-detail 场景中，这读起来更好，按名称对齐更好，并且有更多的逻辑顺序（Master first，Detail second）：

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

相比：

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

原因 4（简单）。总而言之，表名、主键、关系、实体类......最好只知道一个名称（单数）而不是两个（单数类、复数表、单数字段、单数-复数主从... .)

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

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

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

原因 6。（为什么不？）。它甚至可以节省您的书写时间，节省您的磁盘空间，甚至让您的电脑键盘更耐用！

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

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

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

  • 用户 > 登录用户、应用用户、系统用户、CMSUser、...

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

于 2011-04-30T10:56:16.553 回答
274

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

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

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

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

于 2008-12-03T21:09:15.450 回答
264

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

于 2008-12-03T19:31:01.157 回答
258

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

改变表名的数量会导致拼写问题（正如许多其他答案所示），但是因为表通常包含多行而选择这样做在语义上也充满了漏洞。如果我们考虑一种基于大小写变化名词的语言（大多数情况下），这一点会更加明显：

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

使用不变形的名词简单、合乎逻辑、规则且与语言无关。

于 2010-10-08T20:53:37.653 回答
135

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

用户被添加到用户表中。

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

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

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

于 2008-12-03T18:13:04.963 回答
94

举个简单的例子：

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

对比

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

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

我投票给单数。

于 2009-04-04T01:24:47.587 回答
66

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

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

于 2009-01-02T23:38:53.480 回答
45

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

原因？事实上，英语中有不规则复数形式，例如mouse ⇒mice andsheep ⇒sheep。然后，如果我需要收藏，我就用鼠标或羊，然后继续。

它确实有助于突出多样性，我可以轻松地以编程方式确定事物集合的外观。

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

于 2008-12-05T01:15:51.303 回答
40

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

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

于 2009-04-30T21:03:40.927 回答
39

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

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

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

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

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

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

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

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

我喜欢认为它是杂乱无章的，但系统化的——这样，我想表达的关系总有一个系统生成的名称，这对我来说非常重要。

于 2010-12-21T12:49:12.437 回答
31

我也会使用复数形式，并且在前面提到的用户困境中，我们确实采用了方括号方法。

我们这样做是为了在数据库架构和应用程序架构之间提供统一性，从根本上理解，用户表是用户值的集合，就像代码工件中的用户集合是用户对象的集合一样。

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

于 2008-12-03T20:23:56.417 回答
24

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

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

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

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

于 2013-02-26T18:39:51.007 回答
19

单数。我会调用一个包含一堆用户行表示对象“用户”的数组，但该表是“用户表”。认为表只是它包含的行集是错误的，IMO；表是元数据，行集分层地附加到表上，而不是表本身。

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

于 2009-01-02T23:48:27.063 回答
19

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

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

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

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

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

于 2010-09-17T20:10:33.747 回答
16

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

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

我还喜欢将所有 ID 列命名为Id, not ChickenIdor ChickensId(复数的人对此做了什么？)。

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

于 2008-12-03T19:28:09.897 回答
15

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

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

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

于 2008-12-03T19:24:11.123 回答
13

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

于 2008-12-03T20:20:57.187 回答
12

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

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

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

于 2009-01-02T23:50:58.603 回答
12

表：复数

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

型号：单数

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

控制器：复数

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

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

于 2009-11-25T21:23:00.943 回答
12

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

于 2010-10-21T01:37:17.703 回答
12

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

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

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

例如，当我们说：

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

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

于 2012-11-02T21:48:21.003 回答
10

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

于 2012-11-30T16:28:55.490 回答
9

可能的替代方案：

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

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

于 2008-12-03T18:15:08.577 回答
9

这可能有点多余，但我建议谨慎行事。重命名表不一定是坏事，但标准化就是这样；一个标准——这个数据库可能已经“标准化”了，但是很糟糕:)——我建议一致性是一个更好的目标，因为这个数据库已经存在并且可能它包含的不仅仅是 2 个表。

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

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

my2cents ---

于 2008-12-03T18:33:13.207 回答
9

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

示例：一个“college”表可以包含 0 个或多个大学 一个“colleges”表可以包含 0 个或多个 collegues

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

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

于 2011-10-04T18:23:23.380 回答
8

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

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

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

我也尽量避免在表名和列名中使用保留字。在这里有问题的情况下，违反用户的单数约定更有意义，以避免需要封装使用用户保留字的表。

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

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

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

于 2008-12-03T19:11:59.587 回答
8

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

由于英语中的复数不规则性，我想我现在倾向于使用单数。在德语中，由于没有一致的复数形式，情况更糟 - 有时如果没有前面的指定冠词（der/die/das），您无法判断一个单词是否是复数。而且在汉语中，无论如何也没有复数形式。

于 2010-03-10T11:08:31.973 回答
7

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

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

于 2008-12-03T18:17:47.183 回答
7

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

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

于 2012-05-27T18:51:53.647 回答
7

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

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

于 2013-02-18T04:32:25.273 回答
5

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

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

  • tbl用户
  • tblThis
  • tbl那
  • tblTheOther

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

于 2008-12-03T18:19:57.790 回答
5

我只会给出我的意见，为什么我使用单数名称。

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

-- 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'

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

于 2009-01-20T13:57:13.533 回答
5

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

于 2012-11-30T16:24:34.540 回答
4

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

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

于 2008-12-03T20:16:01.267 回答
3

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

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

关于其他问题（引号），它取决于 SQL 方言。Oracle 不需要为表名加上引号。

于 2008-12-03T19:06:57.007 回答
3

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

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

于 2009-11-23T14:34:39.593 回答
3

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

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

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

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

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

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

保存 3 个字符除了含义清晰外没有任何保存。

红色的 ;-）

于 2012-04-09T20:39:20.963 回答
3

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

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
于 2013-06-30T19:09:32.743 回答
3

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

我喜欢你如何阅读这个：

SELECT CustomerName FROM Customers WHERE CustomerID = 100;

我们确实有 OOP，而且很棒，但大多数人继续使用关系数据库，而不是对象数据库。无需遵循关系数据库的 OOP 概念。

另一个例子，你有一个表 Teams，它保留了 TeamID、TeamColor 以及 PlayerID，并且对于一定数量的 PlayerID 将具有相同的 teamID 和 TeamColor...

球员属于哪支球队？

SELECT * FROM Teams WHERE PlayerID = X

X Team的所有球员？

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

于 2013-08-30T14:07:16.997 回答
2

如果您使用 Zend Framework (PHP) 之类的某些框架，最好对表类使用复数，对行类使用单数。

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

现在，如果您对表名使用单数，则必须执行类似 new UserTable() 之类的操作，其中行是 new UserRow()。这对我来说看起来比只为表使用对象 Users() 和为行使用 User() 对象更笨拙。

于 2008-12-03T20:11:06.957 回答
1

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

于 2008-12-03T19:33:52.897 回答