表命名难题：单数与复数名称[关闭]

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

我不喜欢任何需要在名称Users两边加上方括号的T-SQL，但是我将表重命名为单数，永远判刑那些使用该表的人有时不得不使用方括号。

我的直觉是保持单数形式更正确，但我的直觉还是括号表示不需要的内容，例如列名中带有空格等。

我应该走还是留？

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

我有一个相同的问题，在阅读完所有答案后，我肯定会坚持使用SINGULAR，原因如下：

原因1（概念）。您可以想到装有“ AppleBag”之类的苹果的包装袋，无论包含0、1还是一百万个苹果都没有关系，它始终是同一个包装袋。表只是容器，表名必须描述它包含的内容，而不是它包含多少数据。另外，复数概念更多地是关于一种口头语言（实际上是为了确定是否存在一种或多种）。

原因2。（方便）。单数名称比复数名称更容易出现。对象可以具有不规则的复数，也可以根本不具有复数，但总是具有单数（除非有例外，例如“新闻”）。

• 顾客
• 订购
• 用户
• 状态
• 新闻

原因3。（审美和秩序）。特别是在主从方案中，这读起来更好，按名称排列得更好，并且具有更多的逻辑顺序（主优先，细节第二）：

• 1.订购
• 2.OrderDetail

相比：

• 1.OrderDetails
• 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 = 100

您已经保存了3个字母，3个字节和3个额外的键盘按键:)

最后，您可以使用保留名称来命名那些名称，例如：

• 用户> LoginUser，AppUser，SystemUser，CMSUser，...

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

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

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

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

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

我更喜欢用不折弯的名词，英语中的名词恰好是单数。

改写表名的编号会导致拼字问题（如许多其他答案所示），但选择这样做是因为表通常包含多行，从语义上讲也有很多空洞。如果我们考虑一种基于大小写来使名词变位的语言（这与大多数情况一样），则更明显：

由于我们通常对行进行处理，因此为什么不将名称放在宾格中呢？如果我们拥有一个写入表多于读取表的表，为什么不将其名称用字母表示呢？这是一个表的东西，为什么不使用所有格？我们不会这样做，因为表被定义为存在的抽象容器，而不管其状态或用途如何。在没有精确和绝对语义原因的情况下对名词进行折衷是胡说八道。

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

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

用户已添加到“用户”表。

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

该网站不同意（但我不同意）：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比前者听起来更奇怪。

我投票赞成单数。

我坚信，在“实体关系图”中，实体应以单数形式反映，类似于类名是单数形式。一旦实例化，该名称将反映其实例。因此，对于数据库，将实体制成表（实体或记录的集合）时，实体是复数的。实体，用户被制成表用户。我同意其他人的建议，他们建议将“用户”这个名称改进为“雇员”，或者更适合您的情况。

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

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

原因？英语中有不规则的复数形式，如老鼠⇒老鼠和绵羊⇒绵羊。然后，如果我需要一个收藏夹，我就用鼠标或羊皮继续前进。

它确实有助于使多元化脱颖而出，而且我可以轻松地以编程方式确定事物集合的外观。

因此，我的规则是：一切都是单数，事物的每个集合都是单数并附加s。也帮助ORM。

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

如果类名映射到“ 客户”表中的一行，则其名称应与“ 客户”一样为单数形式。

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

我的主要观点是，我不是将表视为集合，而是关系。

因此，该AppUser关系表明哪些实体是AppUsers。

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

该AppUser_AppUserGroup关系告诉我AppUsers和AppUserGroups之间的关系。

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

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

然后，在我的代码和数据库模式中，我使用单数。在文字说明中，我最终使用复数形式以提高可读性-然后使用字体等将表/关系名称与复数s区分开。

我喜欢认为它是凌乱的，但很系统化-这样，对于要表达的关系，总会有系统生成的名称，这对我来说非常重要。

我也将使用复数形式，并使用上述用户困境，我们采取了方括号方法。

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

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

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

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

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

无论大家喜欢什么口味，我都喜欢加蜂蜜煎饼。但是，如果我为别人做饭，我会尽力为他们提供他们喜欢的东西。

单数。我将包含一堆用户行表示对象的数组称为“用户”，但表是“用户表”。IMO将表视为仅包含表中行的集合是错误的；表是元数据，并且行集按层次结构附加到表，而不是表本身。

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

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

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

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

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

老实说，我将重新考虑我在此问题上的立场，我将依靠我所建立的组织所使用的实际惯例。但是，我认为按照我的个人习惯，我会坚持使用复数表名。对我来说更有意义。

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

讽刺的是，我可能会做出User一个例外，称之为Users是因为 USER（Transac-SQL）的缘故，因为我也不想在表周围使用方括号。

我也想将所有ID列命名为Id，而不是 ChickenId或ChickensId（多个人对此怎么做？）。

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

我们运行类似的标准，在脚本编写时，我们需要在名称周围使用[]，并在适当的模式限定符处使用-主要是通过SQL语法对您的赌注进行对冲，以防将来出现名称抢夺的情况。

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

这在过去挽救了我们的灵魂-我们的某些数据库系统从SQL 6.0到SQL 2005已经运行10多年了-超过了预期的使用寿命。

桌子：复数

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

型号：单数

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

控制器：复数

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

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

我喜欢单表名称，因为它们使使用CASE语法的ER图更易于阅读，但是通过阅读这些响应，我感到它从未被很好地接受吗？我个人喜欢它。有一个很好的概述，其中举例说明了使用奇异表名，在关系中添加动作动词并为每个关系形成良好句子时模型的可读性。对于20个表的数据库来说，这有点过头了，但是如果您有一个包含数百个表和复杂设计的DB，那么您的开发人员将如何在缺乏良好可读性的图表的情况下理解它？

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

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

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

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

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

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

例如，当我们说：

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

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

这可能有点多余，但是我建议您要谨慎。重命名表并不一定是一件坏事，但是标准化仅仅是这样。一个标准-这个数据库可能已经“标准化”了，但是很糟糕:)-考虑到这个数据库已经存在并且大概由两个以上的表组成，我建议一致性是一个更好的目标。

除非您可以标准化整个数据库，或者至少计划为此目的工作，否则我怀疑表名只是冰山一角，而专心于手头的任务，可能会遭受名称不佳的对象的痛苦。您最大的兴趣-

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

my2cents-

可能的选择：

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

从技术上讲，IMO使用括号是最安全的方法，尽管它有点麻烦。IMO是六分之一，六分之一，而您的解决方案实际上归结为个人/团队的偏爱。

我认为语义取决于您如何定义容器。例如，一个“苹果袋”或简称为“苹果”或“苹果袋”或“苹果”。

示例：“大学”表可以包含0个或更多大学“大学”表可以包含0个或更多大学

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

我的结论是，两者都很好，但是您必须定义您（或与之交互的人）在引用表时的处理方式。“ ax表”或“ xs表”

就像其他人在这里提到的那样，约定应该成为增加易用性和可读性的工具。不能作为束缚或折磨开发商的俱乐部。

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

这种做法还使我可以为那些在我的对象之间存储多对多关系的表保留多个表名。

我也尽量避免在表名和列名中使用保留字。在这种情况下，针对用户使用单数惯例更有意义，以避免需要封装使用用户保留字的表。

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

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

请记住，约定中最重要的因素是它对与所讨论的数据库进行交互的人员有意义。在命名约定方面，没有“一环可治”。

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

我认为目前我倾向于使用单数形式，因为英语中存在多种不规则现象。在德语中，由于没有一致的复数形式，情况甚至更糟-有时，如果没有单词前面的指定词（der / die / das），您就无法判断单词是否为复数。而且在中国语言中，没有复数形式。

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

我一直使用单数是因为这就是我所教的。但是，在最近创建新架构的过程中，很长一段时间以来，我第一次很主动地决定维护该约定，原因仅仅是……它更短。在每个表名的末尾添加一个“ s”对我来说似乎就像在每个表名之前添加“ tbl_”一样没有用。

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

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

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

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

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

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