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

我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。

我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。

我该留下还是该走?


当前回答

我坚信,在实体关系图中,实体应该用一个单数名称来反映,类似于类名是单数。实例化后,名称将反映其实例。因此,对于数据库,当实体被制成表(实体或记录的集合)时,它是复数。实体,用户被制成表用户。我同意其他人的建议,也许User这个名字可以改为Employee,或者更适合您的场景。

这在SQL语句中更有意义,因为您正在从一组记录中进行选择,如果表名是单数,则读起来不好。

其他回答

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

一些工具(如LLBLGen)可以自动更正多个名称(如用户到用户),而无需更改表名本身。为什么这很重要?因为当它被映射时,你希望它看起来像User.Name而不是User.Name,或者更糟糕的是,我的一些旧数据库表命名为tblUsers.strName,这在代码中令人困惑。

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

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

我更喜欢使用未选择的名词,它在英语中恰好是单数。

影响表名的数量会导致正交问题(正如许多其他答案所示),但选择这样做是因为表通常包含多行,在语义上也充满了漏洞。如果我们考虑一种基于大小写对名词进行屈折的语言(就像大多数语言一样),这一点就更明显了:

既然我们通常都在处理行,为什么不把名字放在宾格中呢?如果我们有一个写得比读得多的表,为什么不把这个名字放在与格中呢?这是一张桌子,为什么不使用属格呢?我们不会这样做,因为表被定义为一个抽象容器,无论其状态或用途如何,它都存在。在没有确切和绝对的语义原因的情况下影响名词是在胡言乱语。

使用未选择的名词是简单、逻辑、规则和语言独立的。

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

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

原因2。(方便)。用单数名字比用复数名字更容易。对象可以有不规则的复数形式,也可以完全没有复数形式,但总是有单数形式(新闻等少数例外)。

顾客顺序使用者地位消息

原因3。(美学和秩序)。特别是在主细节场景中,这读起来更好,按名称排列更好,逻辑顺序更高(主细节优先,细节第二):

1.订单2.订单详情

对比:

1.订单详情2.订单

原因4(简单)。把所有这些放在一起,表名、主键、关系、实体类。。。最好只知道一个名称(单数),而不是两个名称(单一类、复数表、单数字段、单数复数主细节…)

顾客客户.CustomerID客户地址公共类客户{…}从客户选择CustomerID=100

一旦你知道你是在和“客户”打交道,你就可以确定你会对所有的数据库交互需求使用同一个词。

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

原因6。(为什么不呢?)。它甚至可以节省你的写作时间,节省你的磁盘空间,甚至让你的电脑键盘更耐用!

选择客户.CustomerName FROM Customer WHERE Customer.CustomerID=100选择Customers.CustomerName FROM Customers WHERE Customers.CustomerID=103

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

最后,你可以说出那些用保留名搞乱的名字,比如:

用户>LogiUser、AppUser、SystemUser、CMSUser,。。。

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

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

用户将添加到“用户”表中。

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

本网站不同意(但我不同意):http://justinsomnia.org/writings/naming_conventions.html


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

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

此时此刻,我正使用单数名称为我的公司定义一个数据模型,因为大多数工作人员都觉得它更舒服。有时候,你只需要让每个人的生活更轻松,而不是强加你的个人喜好。(这就是我在本主题中的结尾,以确认什么是命名表的“最佳实践”)

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

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