学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
当前回答
如果您使用对象关系映射工具,或者将来会使用,我建议您使用Singular。
一些工具(如LLBLGen)可以自动更正多个名称(如用户到用户),而无需更改表名本身。为什么这很重要?因为当它被映射时,你希望它看起来像User.Name而不是User.Name,或者更糟糕的是,我的一些旧数据库表命名为tblUsers.strName,这在代码中令人困惑。
我的新经验法则是判断它转换成对象后的外观。
我发现一个不适合我使用的新命名的表是UsersInRoles。但总会有一些例外情况,即使在这种情况下,它看起来也很像UsersInRoles.Username。
其他回答
我不喜欢复数表名,因为英语中的一些名词是不可数的(水、汤、现金),或者当你使其可数时,其含义会发生变化(鸡vs鸡;肉vs鸟)。我也不喜欢使用表名或列名的缩写,因为这样做会给已经陡峭的学习曲线增加额外的斜率。
具有讽刺意味的是,我可能会将User作为一个例外,并将其称为User,因为User(Transac SQL),因为如果不需要的话,我也不喜欢在表周围使用括号。
我还喜欢将所有ID列命名为ID,而不是ChickenId或ChickenId(复数个家伙对此做什么?)。
这一切都是因为我对数据库系统没有适当的尊重,我只是在重新应用OO命名约定中的一个技巧,比如Java的习惯和懒惰。我希望有更好的IDE支持复杂的SQL。
正如其他人在这里提到的,约定应该是一种工具,可以增加易用性和可读性。不是用来折磨开发者的枷锁或俱乐部。
也就是说,我个人倾向于对表和列使用单数名称。这可能来自我的编程背景。类名通常是单数,除非它们是某种集合。在我的脑海中,我正在存储或读取相关表中的单个记录,所以单数对我来说是有意义的。
这种做法还允许我为那些在对象之间存储多对多关系的表保留多个表名。
我也尽量避免在表和列名中使用保留字。在这里所讨论的情况下,违背用户的单一约定更有意义,以避免需要封装使用User的保留字的表。
我喜欢以有限的方式使用前缀(tbl表示表名,sp_表示进程名等),尽管许多人认为这会增加混乱。与下划线相比,我更喜欢CamelBack名称,因为我在键入名称时总是按+而不是_。许多人不同意。
下面是命名约定指南的另一个好链接:http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/
请记住,您的惯例中最重要的因素是,它对与所讨论的数据库交互的人来说是有意义的。在命名惯例方面,没有“一个戒指来统治所有人”。
可能的替代方案:
重命名表SystemUser使用括号保留多个表名。
IMO使用括号从技术上来说是最安全的方法,尽管它有点麻烦。IMO是一个6个,另一个6打,您的解决方案实际上只是归结为个人/团队偏好。
我曾经在User表中使用过“Dude”——同样短的字符数,与关键字没有冲突,仍然是对普通人的引用。如果我不担心那些可能看到代码的愚蠢的人,我会一直这样做。
我坚信,在实体关系图中,实体应该用一个单数名称来反映,类似于类名是单数。实例化后,名称将反映其实例。因此,对于数据库,当实体被制成表(实体或记录的集合)时,它是复数。实体,用户被制成表用户。我同意其他人的建议,也许User这个名字可以改为Employee,或者更适合您的场景。
这在SQL语句中更有意义,因为您正在从一组记录中进行选择,如果表名是单数,则读起来不好。