学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
当前回答
我坚信,在实体关系图中,实体应该用一个单数名称来反映,类似于类名是单数。实例化后,名称将反映其实例。因此,对于数据库,当实体被制成表(实体或记录的集合)时,它是复数。实体,用户被制成表用户。我同意其他人的建议,也许User这个名字可以改为Employee,或者更适合您的场景。
这在SQL语句中更有意义,因为您正在从一组记录中进行选择,如果表名是单数,则读起来不好。
其他回答
如果您使用对象关系映射工具,或者将来会使用,我建议您使用Singular。
一些工具(如LLBLGen)可以自动更正多个名称(如用户到用户),而无需更改表名本身。为什么这很重要?因为当它被映射时,你希望它看起来像User.Name而不是User.Name,或者更糟糕的是,我的一些旧数据库表命名为tblUsers.strName,这在代码中令人困惑。
我的新经验法则是判断它转换成对象后的外观。
我发现一个不适合我使用的新命名的表是UsersInRoles。但总会有一些例外情况,即使在这种情况下,它看起来也很像UsersInRoles.Username。
可能的替代方案:
重命名表SystemUser使用括号保留多个表名。
IMO使用括号从技术上来说是最安全的方法,尽管它有点麻烦。IMO是一个6个,另一个6打,您的解决方案实际上只是归结为个人/团队偏好。
如果我们查看MS SQL Server的系统表,Microsoft指定的表名是复数。
Oracle的系统表以单数形式命名。尽管其中有几个是复数。Oracle建议用户定义的表名使用复数。他们推荐一件事而遵循另一件事,这没有多大意义。这两个软件巨头的架构师使用不同的约定来命名他们的表,这也没有多大意义。。。毕竟,这些家伙是什么。。。博士学位?
我记得在学术界,这项建议是独一无二的。
例如,当我们说:
select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'
也许b/c每个ID都是从特定的单行中选择的。。。?
在寻找良好的命名惯例时,我应该如何命名会出现以下困惑:
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
我的看法是语义上的,这取决于您如何定义容器。例如,“一袋苹果”或简单的“苹果”或“苹果袋”或“apple”。
例子:“学院”表可以包含0个或多个学院“学院”表可以包含0个或多个学院
a "student" table can contain 0 or more students
a table of "students" can contain 0 or more students.
我的结论是,两者都可以,但你必须定义你(或与之互动的人)在参考表格时将如何处理;“x表”或“xs表”