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

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

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

我该留下还是该走?


当前回答

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

0条记录1条记录许多记录。

你到底为什么要在一个对象名称的末尾加一个“s”?将“s”放在对象名称的末尾,表示什么意思?

如果要区分,请添加“_tbl”。视图是“_vew”(而不是愚蠢的“_v”约定)。

最少3个字符的后缀-这会使讨论停止。

表是一个DB对象,与其他对象没有区别。

保存3个字符只会使意思清晰。

红色;-)

其他回答

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

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

至于表和视图的前缀,我绝对讨厌这种做法。在给一个人提供可能不好的信息之前,不要给他任何信息。任何浏览数据库查找对象的人都可以很容易地将表与视图区分开来,但如果我有一个名为tblUsers的表,出于某种原因,我决定在将来将其重组为两个表,并使用一个视图统一它们,以防破坏旧代码,那么我现在有一个名称为tblUser的视图。此时,我只剩下两个没有吸引力的选项:留下一个带有tbl前缀的视图,这可能会让一些开发人员感到困惑,或者强制重写另一个层(中间层或应用程序),以引用我的新结构或名称viewUsers。这否定了IMHO视图的大部分价值。

指导方针确实如此。这不是“板上钉钉”,这就是为什么你可以选择忽略它们。

我想说,使用多个表名在逻辑上更直观。表毕竟是实体的集合。除了提到的其他选项,我通常在表名上看到前缀。。。

tbl用户tbl此待定tbl其他

我并不是建议这样做,我也看到表名中使用了很多空格,我对此深恶痛绝。我甚至遇到过带有白痴字符的域名,比如?好像说这个字段回答了一个问题。

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

我的看法是语义上的,这取决于您如何定义容器。例如,“一袋苹果”或简单的“苹果”或“苹果袋”或“apple”。

例子:“学院”表可以包含0个或多个学院“学院”表可以包含0个或多个学院

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

我的结论是,两者都可以,但你必须定义你(或与之互动的人)在参考表格时将如何处理;“x表”或“xs表”

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

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