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

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

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

我该留下还是该走?


当前回答

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

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

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

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


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

其他回答

我通过将表命名为“雇员”(实际上是“雇员”)来解决同样的问题。我尽量避免与可能保留的单词发生冲突。即使是“用户”对我来说也很近。

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

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

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

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


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

在寻找良好的命名惯例时,我应该如何命名会出现以下困惑:

1) 根据桌子上的东西用户表。它总是复数形式。所以,用户

2) 根据记录的内容用户表中的记录将是单个用户。SO,用户。

现在,主要是用户角色的问题。情况1:根据第一命名约定,users_roles此名称的含义、用户及其角色。

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

良好的命名约定是提供实体关系的额外概念,尤其是当存储多对多关系时。

在这里,根据场景,我们应该确定为一组信息。

在用户表中,形成的所有集合都是唯一的用户。在“角色”表中,形成的所有集合都是唯一的角色。在用户和角色关系表中,可以用不同的角色组成用户集,这给出了存储1个任意关系的概念。

I would prefer,
Users table => user
Roles table => role
users role relationship table => user_roles

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

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

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

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

我也会使用复数形式,对于前面提到的用户困境,我们确实采用了方括号方法。

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

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