表命名难题:单数与复数名称

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

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

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

我是该留下还是该离开?

答案

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

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

原因 2 。 (方便)。单数名称比复数名称更容易出现。对象可以具有不规则的复数,也可以根本不具有复数,但始终将具有单数(除了 News 等少数例外)。

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

原因 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 一样好。

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

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

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

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

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

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

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

本网站同意:
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。

恕我直言,表名应该像Customer一样是复数形式

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

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

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

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

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

AppUser_AppUserGroup关系告诉我AppUsersAppUserGroups是如何关联的。

AppUserGroup_AppUserGroup关系告诉我AppUserGroupsAppUserGroups是如何关联的(即组的组成员)。

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

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

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