学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
当前回答
这可能有点多余,但我建议谨慎行事。重命名表不一定是坏事,但标准化就是这样;一个标准——这个数据库可能已经被“标准化”了,无论多么糟糕:)——我建议一致性是一个更好的目标,因为这个数据库已经存在,而且它可能不仅仅由两个表组成。
除非您能够标准化整个数据库,或者至少计划为此目的而努力,否则我怀疑表名只是冰山一角,专注于手头的任务,忍受命名不好的对象的痛苦,可能符合您的最大利益--
实际一致性有时是最佳标准…:)
my2内容---
其他回答
两个网站都有不同的论文,我认为你只需要选择你的一方。就我个人而言,我更喜欢Plular来命名表,当然,单数来命名列。
我喜欢你怎么读这个:
SELECT CustomerName FROM Customers WHERE CustomerID = 100;
的确,我们有OOP,这很好,但大多数人仍然使用关系数据库,而不是对象数据库。关系数据库不需要遵循OOP概念。
另一个例子是,您有一个表Teams,它保存了TeamID、TeamColor和PlayerID,并且对于一定数量的PlayerID将具有相同的TeamID和TeamColor。。。
该球员属于哪支球队?
SELECT * FROM Teams WHERE PlayerID = X
X队的所有球员?
SELECT * FROM Players INNER JOIN Teams ON Players.PlayerID = Teams.PlayerID WHERE Teams.TeamID = X
你觉得这一切都好吗?
无论如何,还可以看看W3Schools使用的命名约定:
http://www.w3schools.com/sql/sql_join_inner.asp
这可能有点多余,但我建议谨慎行事。重命名表不一定是坏事,但标准化就是这样;一个标准——这个数据库可能已经被“标准化”了,无论多么糟糕:)——我建议一致性是一个更好的目标,因为这个数据库已经存在,而且它可能不仅仅由两个表组成。
除非您能够标准化整个数据库,或者至少计划为此目的而努力,否则我怀疑表名只是冰山一角,专注于手头的任务,忍受命名不好的对象的痛苦,可能符合您的最大利益--
实际一致性有时是最佳标准…:)
my2内容---
如果我们查看MS SQL Server的系统表,Microsoft指定的表名是复数。
Oracle的系统表以单数形式命名。尽管其中有几个是复数。Oracle建议用户定义的表名使用复数。他们推荐一件事而遵循另一件事,这没有多大意义。这两个软件巨头的架构师使用不同的约定来命名他们的表,这也没有多大意义。。。毕竟,这些家伙是什么。。。博士学位?
我记得在学术界,这项建议是独一无二的。
例如,当我们说:
select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'
也许b/c每个ID都是从特定的单行中选择的。。。?
指导方针确实如此。这不是“板上钉钉”,这就是为什么你可以选择忽略它们。
我想说,使用多个表名在逻辑上更直观。表毕竟是实体的集合。除了提到的其他选项,我通常在表名上看到前缀。。。
tbl用户tbl此待定tbl其他
我并不是建议这样做,我也看到表名中使用了很多空格,我对此深恶痛绝。我甚至遇到过带有白痴字符的域名,比如?好像说这个字段回答了一个问题。
单数的我会将包含一组用户行表示对象的数组称为“用户”,但该表是“用户表”。国际海事组织认为,表只是它所包含的一组行,这是错误的;表是元数据,行集是分层地附加到表的,而不是表本身。
当然,我一直使用ORM,用多个表名编写的ORM代码看起来很愚蠢,这有助于提高效率。