学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
当前回答
单数的我不相信任何涉及最合乎逻辑的论点——每个人都认为自己的偏好最合乎逻辑。无论你做什么,这都是一团糟,只要选择一个惯例并坚持下去。我们正试图将一种语法和语义高度不规则的语言(正常的口语和书面语言)映射到一种具有非常特定语义的高度规则(SQL)语法。
我的主要论点是,我不认为表格是一个集合,而是一个关系。
因此,AppUser关系告诉哪些实体是AppUsers。
AppUserGroup关系告诉哪些实体是AppUserGroups
AppUser_AppUserGroup关系告诉AppUsers和AppUserGroups是如何关联的。
AppUserGroup_AppUserGroup关系告诉AppUserGroups和AppUserGroup是如何关联的(即组中的组成员)。
换句话说,当我想到实体以及它们是如何关联的时候,我想到的是单数的关系,但当然,当我想起集合或集合中的实体时,集合或集合是复数的。
在我的代码和数据库模式中,我使用单数。在文本描述中,为了提高可读性,我最终使用了复数形式,然后使用字体等将表/关系名称与复数形式区分开来。
我喜欢认为它是混乱的,但有系统的——这样,我想表达的关系总是有一个系统生成的名称,这对我来说非常重要。
其他回答
这可能有点多余,但我建议谨慎行事。重命名表不一定是坏事,但标准化就是这样;一个标准——这个数据库可能已经被“标准化”了,无论多么糟糕:)——我建议一致性是一个更好的目标,因为这个数据库已经存在,而且它可能不仅仅由两个表组成。
除非您能够标准化整个数据库,或者至少计划为此目的而努力,否则我怀疑表名只是冰山一角,专注于手头的任务,忍受命名不好的对象的痛苦,可能符合您的最大利益--
实际一致性有时是最佳标准…:)
my2内容---
如果您使用Zend Framework(PHP)等特定框架,那么明智的做法是表类使用复数,行类使用单数。
因此,假设您创建了一个表对象$users=newUsers(),并将行类声明为User,那么您也可以调用newUser()。
现在,如果对表名使用单数,则必须执行类似于newUserTable()的操作,其中的行是newUserRow()。对我来说,这看起来比为表设置对象Users()和为行设置User()对象更笨拙。
如果你去那里会有麻烦,但如果你留下来,麻烦就会加倍。
我宁愿违背一些假定的非复数命名惯例,也不愿用可能是保留词的名称来命名我的表。
我是单数表名的粉丝,因为它们使用CASE语法使我的ER图更容易阅读,但通过阅读这些响应,我感到它从未很好地被理解?我个人很喜欢它。这里有一个很好的概述,举例说明当你使用单数表名,在你的关系中添加动作动词,并为每一种关系形成好句子时,你的模型是多么可读。对于一个20表的数据库来说,这有点过分了,但是如果您有一个包含数百个表的数据库,并且设计复杂,如果没有一个可读性好的图表,您的开发人员将如何理解它?
http://www.aisintl.com/case/method.html
至于表和视图的前缀,我绝对讨厌这种做法。在给一个人提供可能不好的信息之前,不要给他任何信息。任何浏览数据库查找对象的人都可以很容易地将表与视图区分开来,但如果我有一个名为tblUsers的表,出于某种原因,我决定在将来将其重组为两个表,并使用一个视图统一它们,以防破坏旧代码,那么我现在有一个名称为tblUser的视图。此时,我只剩下两个没有吸引力的选项:留下一个带有tbl前缀的视图,这可能会让一些开发人员感到困惑,或者强制重写另一个层(中间层或应用程序),以引用我的新结构或名称viewUsers。这否定了IMHO视图的大部分价值。
如果您使用对象关系映射工具,或者将来会使用,我建议您使用Singular。
一些工具(如LLBLGen)可以自动更正多个名称(如用户到用户),而无需更改表名本身。为什么这很重要?因为当它被映射时,你希望它看起来像User.Name而不是User.Name,或者更糟糕的是,我的一些旧数据库表命名为tblUsers.strName,这在代码中令人困惑。
我的新经验法则是判断它转换成对象后的外观。
我发现一个不适合我使用的新命名的表是UsersInRoles。但总会有一些例外情况,即使在这种情况下,它看起来也很像UsersInRoles.Username。