关于SQL表复数名称命名的困境：Singular vs. Plural Names


Table Naming Dilemma: Singular vs. Plural Names

学术界认为，表名应该是存储其属性的实体的唯一性。

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

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

我该留下还是该走？

相关讨论

我也有同样的问题，在阅读了所有答案后，我肯定会留下单一的理由：

原因1(概念)。你可以把装苹果的袋子想象成"苹果袋"，不管是装0个，1个还是100万个苹果，都是同一个袋子。表只是容器，表名必须描述它包含什么，而不是它包含多少数据。此外，复数概念更多的是关于一种口语(实际上是为了确定是否有一种或多种)。

原因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 = 100

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

最后，你可以把那些乱七八糟的保留名称命名为：

  • 用户>登录用户，应用用户，系统用户，CMSUSER，…

或者使用不知名的方括号[用户]

相关讨论

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

有些工具(如llblgen)可以自动将用户等复数名称更正为用户，而无需更改表名本身。为什么这很重要？因为当它被映射时，您希望它看起来像user.name而不是user s.name，或者更糟的是，我的一些旧数据库表命名为tblusers.strname，这在代码中很混乱。

我的新经验法则是判断它被转换成物体后的样子。

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

相关讨论

就"标准"而言，其他人给出了相当好的答案，但我只是想补充一下……"用户"(或"用户")是否可能不是表中所含数据的完整描述？并不是说你应该对表名和特定性过于疯狂，而是像"widget-users"(其中"widget"是应用程序或网站的名称)这样的东西更合适。

相关讨论

我更喜欢使用未经修饰的名词，在英语中，它恰好是单数。

改变表名的数目会导致正交问题(如许多其他答案所示)，但选择这样做是因为表通常包含多个行，在语义上也充满了漏洞。如果我们考虑一种根据大小写改变名词的语言，这一点就更明显了(大多数情况都是这样)：

既然我们通常是在处理行，为什么不把这个名字放在指控的案例中呢？如果我们有一张写得比读得多的表，为什么不把这个名字放在dative中呢？这是一张桌子，为什么不使用属灵？我们不会这样做，因为表被定义为一个抽象容器，不管其状态或用法如何，都存在。词义上没有精确和绝对的原因而改变名词的词形是胡言乱语。

使用未经修饰的名词是简单的、逻辑的、规则的和语言无关的。

相关讨论

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

用户将添加到用户表中。

本网站同意：http://vyaskn.tripod.com/object_naming.htm表格

此网站不同意(但我不同意)：http://justinsmnia.org/writings/naming_conventions.html

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

相关讨论

举个简单的例子吧：

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

VS

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

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

我投票赞成单数。

相关讨论

我坚信，在一个实体关系图中，实体应该用一个单数名称来反映，类似于类名是单数。一旦实例化，该名称将反映其实例。因此，对于数据库，当实体构成一个表(实体或记录的集合)时，它是复数。实体，用户被制成表用户。我同意其他人的意见，他们建议可以将名称用户改进为员工或更适用于您的方案。

这在SQL语句中更有意义，因为您从一组记录中进行选择，如果表名是单数的，那么它的可读性就不好。

相关讨论

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

原因何在？事实上，在英语中有不规则复数，比如鼠标？老鼠和绵羊？绵羊。然后，如果我需要收藏，我就用鼠标或羊皮，然后继续。

这真的有助于多元性的突出，我可以很容易和程序化地确定收集的东西是什么样子的。

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

相关讨论

单数的。我不赞成任何最合乎逻辑的论点——每个人都认为自己的偏好是最合乎逻辑的。不管你做什么，都是一团糟，只需选择一个惯例并坚持下去。我们试图将语法和语义高度不规则的语言(正常的口头和书面语言)映射为具有非常具体语义的高度规则(SQL)语法。

我的主要论点是，我不把表看作集合，而是把表看作关系。

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

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

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

AppUserGroup_AppUserGroup关系告诉我AppUserGroups和AppUserGroups是如何联系的(即群体成员)。

换言之，当我想到实体以及它们是如何相关的时，我想到的关系是单数的，但是当我想到集合或集合中的实体时，集合或集合是复数的。

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

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

相关讨论

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

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

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

相关讨论

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

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

我个人更喜欢用复数来代表一个集合，它只是"听起来"对我的关系头脑更好。

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

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

我喜欢我的蜂蜜煎饼，不管大家最喜欢什么口味。但如果我为别人做饭，我会尽力为他们提供他们喜欢的食物。

相关讨论

单数的。我将调用一个包含一组用户行表示对象的数组"users"，但该表是"用户表"。把表看作是它所包含的行的集合是错误的，IMO；表是元数据，行的集合是分层附加到表上的，而不是表本身。

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

相关讨论

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

具有讽刺意味的是，我可能会将User作为一个例外，并因为用户(transac-sql)而将其称为Users，因为如果不需要的话，我也不喜欢在表周围使用方括号。

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

所有这些都是因为我对数据库系统没有适当的尊重，我只是在从OO命名约定中重新应用一个技巧，比如Java的习惯和懒惰。我希望对复杂的SQL有更好的IDE支持。

相关讨论

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

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

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

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

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

相关讨论

我们运行类似的标准，当编写脚本时，我们要求在名称周围使用[]，并且在适当的情况下使用模式限定符——主要是它对冲您对SQL语法将来获取的名称的赌注。

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

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

相关讨论

服务器本身的系统tables/views(SYSCAT.TABLES、dbo.sysindexes、ALL_TABLES、information_schema.columns等)几乎总是复数。我想为了保持一致，我会听从他们的领导。

相关讨论

我是一个单一表名的爱好者，因为它们使我的ER图表使用case语法更容易阅读，但通过阅读这些响应，我感觉它从来没有被很好地抓住？我个人很喜欢。这里有一个很好的概述，举例说明当您使用单数表名、在关系中添加动作动词以及为每个关系形成好的句子时，模型的可读性如何。对于一个20表的数据库来说，这有点过分了，但是如果您有一个包含数百个表的数据库，并且设计复杂，那么如果没有一个可读性好的图表，您的开发人员将如何理解它呢？

网址：http://www.aisintl.com/case/method.html

至于前缀表和视图，我绝对讨厌这种做法。在给一个人可能不好的信息之前，完全不给他任何信息。任何浏览数据库中的对象的人都可以很容易地从视图中分辨出一个表，但是如果我有一个名为tblusers的表，出于某种原因，我决定在将来将它重组为两个表，通过一个视图将它们统一起来以避免破坏旧代码，我现在有一个名为tblusers的视图。此时，我只剩下两个没有吸引力的选项，一个名为tbl前缀的视图可能会使一些开发人员感到困惑，或者强制另一个层(中间层或应用程序)重写以引用我的新结构或名称viewusers。这否定了视图imho的大部分价值。

相关讨论

表：复数形式

Multiple users are listed in the users table.

模型：单数

A singular user can be selected from the users table.

控制器：复数

http://myapp.com/users would list multiple users.

不管怎样，这是我的看法。

相关讨论

我的观点是语义上的，这取决于您如何定义容器。例如，一个"苹果袋"或者简单的"苹果"，或者一个"苹果袋"或者"苹果"。

例子："大学"表可以包含0个或多个大学"学院"表可以包含0个或多个学院

1
2
a"student" TABLE can contain 0 OR more students
a TABLE OF"students" can contain 0 OR more students.

我的结论是，要么是好的，但你必须定义你(或与之交互的人)在引用表时将如何处理；"x表"或"x表"

这可能有点多余，但我建议谨慎行事。不一定重命名表是件坏事，但是标准化就是这样；一个标准——这个数据库可能已经"标准化"，但是很糟糕：)——我建议一致性是一个更好的目标，因为这个数据库已经存在，而且可能包含两个以上的表。

除非您能够标准化整个数据库，或者至少计划朝着这个目标努力，否则我怀疑表名只是冰山一角，专注于手头的任务，忍受命名不好的对象的痛苦，可能对您最有利。--

实践的一致性有时是最好的标准…：)

My2美分

如果我们查看MS SQL Server's系统表，微软指定的名称在plural中。

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

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

例如，当我们说：

1
SELECT OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

也许每个ID的B/C都是从一个特定的单行中选择的…？

相关讨论

可能的替代方案：

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

在技术上，使用支架是最安全的方法，尽管有点麻烦。在我看来，这是六分之一，六分之一，而你的解决方案实际上就是个人/团队的偏好。

相关讨论

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

我想我现在倾向于使用单数，因为英语中存在复数形式的不规则。在德语中，由于没有一致的复数形式，情况更糟——有时，如果没有前面的指定词(der/die/das)，就无法分辨一个词是复数还是非复数。在汉语中，也没有复数形式。

我总是用单数，因为我是这么学的。然而，在最近创建一个新模式的同时，在很长一段时间内，我第一次主动地决定维护这个约定，仅仅是因为…它短一些。在每个表名的末尾添加"s"对我来说就像在每个表名前面添加"tbl_uuu"一样无用。

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

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

这个实践还允许我为那些存储对象之间多对多关系的表保留复数名称。

我尽量避免在表名和列名中使用保留字。在这里讨论的情况下，为了避免需要封装使用用户保留字的表，对用户来说违背单一约定更为合理。

我喜欢以有限的方式使用前缀(表名为tbl，过程名为sp_u等)，尽管许多人认为这会增加混乱。我更喜欢驼背式的名字而不是下划线，因为我在输入名字时总是按+而不是u。其他许多人不同意。

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

请记住，在您的约定中，最重要的因素是它对与相关数据库交互的人有意义。当涉及到命名约定时，没有"一个环来规则它们"。

相关讨论

我曾经用"dude"来表示用户表——同样的短字符数，与关键字没有冲突，仍然是对一般人的引用。如果我不关心那些可能看到代码的闷头，我会保持这种状态。

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

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

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

(我认为该策略背后的理性是，ORM代码生成器更容易生成对象和集合类，因为从单一名称生成复数名称比从单一名称生成复数名称更容易，反之亦然)

相关讨论

指导方针就是这样。这不是"一石二鸟"，这就是为什么你可以选择忽略它们。

我想说，用复数形式的表名更符合逻辑。表毕竟是实体的集合。除了提到的其他替代方法之外，我还经常看到表名上的前缀…

  • 漏斗
  • TBLIST
  • TBLID
  • 其他人

我不是建议这样做，我也看到表名中使用了很多我讨厌的空格。我甚至遇到过有白痴性格的外号，比如？好像说这个领域回答了一个问题。

相关讨论

我只想说明我为什么用单数。

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

1
2
-- Select every fields from 'user' table
SELECT * FROM USER

我需要21岁用户的姓名：

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

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

相关讨论

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

相关讨论

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

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

相关讨论

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

我更愿意反对一些所谓的非复数命名约定，而不是用一些可能是保留字的词来命名我的表。

我没有在之前的回答中清楚地看到这一点。许多程序员在处理表时没有考虑到正式的定义。我们经常以"记录"或"行"的形式进行直观的交流。但是，除了非规范化关系的一些例外，通常设计表，使非键属性与键之间的关系构成一个集合理论函数。

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

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

例如，我们在评级流程使用的数据库上有一个名为"拒绝"的表，其中包含从程序一次运行中拒绝的记录，我看不到不使用该表的复数形式的任何原因(将其命名为"拒绝"只会很有趣，或者过于乐观)。
BR/>关于另一个问题(引号)，它取决于SQL方言。Oracle不需要在表名周围加引号。

相关讨论

如果您使用Zend框架(PHP)这样的特定框架，那么对于表类使用复数，对于行类使用单数是明智的。

所以假设您创建了一个表对象$users=new users()，并且已经将row类声明为user，那么您也可以调用new user()。

现在，如果对表名使用单数形式，则必须执行诸如new usertable()之类的操作，其中该行是new userrow()。对于我来说，这看起来比只为表设置一个object users()和为行设置user()对象更笨拙。

相关讨论

在寻找好的命名约定的同时，我应该命名以下混乱：

1)根据桌子的位置一张用户表。它总是复数。所以，用户

2)根据记录的内容用户表中的记录将是单个用户。所以，用户。

现在，主要是用户角色的问题。案例1：根据第一个命名约定，用户角色这个名字的含义，用户及其角色。

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

好的命名约定是为实体关系提供一个额外的概念，特别是在存储多对多关系时。

在这里，根据场景，我们应该将其标识为一组信息。

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

1
2
3
4
I would prefer,
Users TABLE => USER
Roles TABLE => ROLE
users ROLE relationship TABLE => user_roles

表名是表结构的一个定义。视图或查询名称是(一个或多个)表的视图或查询的一个定义。表、视图或查询可以包含以下内容之一：

0记录1记录许多记录。

你到底为什么要在一个物体名称的末尾加上"s"？将"s"放在对象名称的末尾，表示什么？

如果要区分，请添加"_-tbl"。一种观点是"素食"(不是愚蠢的"素食"惯例)。

至少3个字符的后缀-使讨论停止。

表是一个数据库对象-与其他对象没有区别。

保存3个字符只会节省意义的清晰度。

红色；-)

相关讨论

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

我喜欢你怎么读这个：

1
SELECT CustomerName FROM Customers WHERE CustomerID = 100;

实际上，我们有OOP，而且很好，但是大多数人都在使用关系数据库，没有对象数据库。没有必要遵循关系数据库的OOP概念。

另一个例子是，您有一个表团队，它保留teamid、teamcolor和playerid，并且在一定数量的playerid中具有相同的teamid和teamcolor…

球员属于哪个队？

1
SELECT * FROM Teams WHERE PlayerID = X

所有来自X队的球员？

1
SELECT * FROM Players INNER JOIN Teams ON Players.PlayerID = Teams.PlayerID WHERE Teams.TeamID = X

你觉得这一切都好吗？

无论如何，还可以看看W3学校使用的命名约定：

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

我通过将表命名为"Employee"(实际上是"Employees")来解决相同的问题。我尽量避免与可能保留的词语发生冲突。即使是"用户"对我来说也非常接近。

相关讨论