学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
当前回答
什么约定要求表具有单数名称?我一直以为是复数。
用户将添加到“用户”表中。
本网站同意:http://vyaskn.tripod.com/object_naming.htm#Tables
本网站不同意(但我不同意):http://justinsomnia.org/writings/naming_conventions.html
正如其他人所提到的:这些只是指导方针。选择一个适合你和你的公司/项目的惯例,并坚持下去。在单数和复数之间切换,或者有时缩写词,有时不缩写词,这会让人更加恼火。
其他回答
我的看法是语义上的,这取决于您如何定义容器。例如,“一袋苹果”或简单的“苹果”或“苹果袋”或“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
如果您使用Zend Framework(PHP)等特定框架,那么明智的做法是表类使用复数,行类使用单数。
因此,假设您创建了一个表对象$users=newUsers(),并将行类声明为User,那么您也可以调用newUser()。
现在,如果对表名使用单数,则必须执行类似于newUserTable()的操作,其中的行是newUserRow()。对我来说,这看起来比为表设置对象Users()和为行设置User()对象更笨拙。
我在之前的任何回答中都没有看到这一点。许多程序员在处理表时没有正式的定义。我们经常以“记录”或“行”的形式直观地交流。然而,除了一些非规范化关系的例外,表通常被设计为使得非键属性和键之间的关系构成集合论函数。
函数可以定义为两个集合之间的叉积的子集,其中键集合的每个元素在映射中最多出现一次。因此,从这个角度产生的术语往往是单数。在涉及函数的其他数学和计算理论(例如代数和lambda演算)中,人们可以看到相同的单数(或至少是非复数)约定。
这可能有点多余,但我建议谨慎行事。重命名表不一定是坏事,但标准化就是这样;一个标准——这个数据库可能已经被“标准化”了,无论多么糟糕:)——我建议一致性是一个更好的目标,因为这个数据库已经存在,而且它可能不仅仅由两个表组成。
除非您能够标准化整个数据库,或者至少计划为此目的而努力,否则我怀疑表名只是冰山一角,专注于手头的任务,忍受命名不好的对象的痛苦,可能符合您的最大利益--
实际一致性有时是最佳标准…:)
my2内容---