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

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

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

我该留下还是该走?


当前回答

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

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

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

其他回答

这可能有点多余,但我建议谨慎行事。重命名表不一定是坏事,但标准化就是这样;一个标准——这个数据库可能已经被“标准化”了,无论多么糟糕:)——我建议一致性是一个更好的目标,因为这个数据库已经存在,而且它可能不仅仅由两个表组成。

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

实际一致性有时是最佳标准…:)

my2内容---

如果您使用Zend Framework(PHP)等特定框架,那么明智的做法是表类使用复数,行类使用单数。

因此,假设您创建了一个表对象$users=newUsers(),并将行类声明为User,那么您也可以调用newUser()。

现在,如果对表名使用单数,则必须执行类似于newUserTable()的操作,其中的行是newUserRow()。对我来说,这看起来比为表设置对象Users()和为行设置User()对象更笨拙。

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

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

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

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


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

没有要求表名为单数的“约定”。例如,我们在一个评级过程使用的数据库中有一个名为“REJECTS”的表,其中包含了一次运行程序时被拒绝的记录,我看不出任何理由不使用复数形式来表示该表(将其命名为“REJECT”会很有趣,或者过于乐观)。关于另一个问题(引号),它取决于SQL方言。Oracle不要求在表名周围加引号。

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

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