学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
当前回答
IMHO,表名应该是复数,如Customer。
如果类名称映射到Customers表中的一行,则类名称应与Customer类似。
其他回答
我不喜欢复数表名,因为英语中的一些名词是不可数的(水、汤、现金),或者当你使其可数时,其含义会发生变化(鸡vs鸡;肉vs鸟)。我也不喜欢使用表名或列名的缩写,因为这样做会给已经陡峭的学习曲线增加额外的斜率。
具有讽刺意味的是,我可能会将User作为一个例外,并将其称为User,因为User(Transac SQL),因为如果不需要的话,我也不喜欢在表周围使用括号。
我还喜欢将所有ID列命名为ID,而不是ChickenId或ChickenId(复数个家伙对此做什么?)。
这一切都是因为我对数据库系统没有适当的尊重,我只是在重新应用OO命名约定中的一个技巧,比如Java的习惯和懒惰。我希望有更好的IDE支持复杂的SQL。
表的SQL定义实际上是表的一个潜在行的定义,而不是集合。因此,该定义中使用的名称必须指定行的类型,而不是集合的名称。那些喜欢复数的人,因为它在他们的英语语句中读起来很好,他们需要开始更逻辑地思考,并查看实际使用表所涉及的所有逻辑和编程代码。这些注释中提到了使用单数表名的几个很好的理由。其中包括不使用多个表名的充分理由。“好好读书”根本不应该是任何理由,尤其是因为有些人可能会以不同的方式来理解这个想法。
两个网站都有不同的论文,我认为你只需要选择你的一方。就我个人而言,我更喜欢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
我更喜欢使用未选择的名词,它在英语中恰好是单数。
影响表名的数量会导致正交问题(正如许多其他答案所示),但选择这样做是因为表通常包含多行,在语义上也充满了漏洞。如果我们考虑一种基于大小写对名词进行屈折的语言(就像大多数语言一样),这一点就更明显了:
既然我们通常都在处理行,为什么不把名字放在宾格中呢?如果我们有一个写得比读得多的表,为什么不把这个名字放在与格中呢?这是一张桌子,为什么不使用属格呢?我们不会这样做,因为表被定义为一个抽象容器,无论其状态或用途如何,它都存在。在没有确切和绝对的语义原因的情况下影响名词是在胡言乱语。
使用未选择的名词是简单、逻辑、规则和语言独立的。
我个人更喜欢用复数来表示一个集合,这对我的关系思维来说“听起来”更好。
此时此刻,我正使用单数名称为我的公司定义一个数据模型,因为大多数工作人员都觉得它更舒服。有时候,你只需要让每个人的生活更轻松,而不是强加你的个人喜好。(这就是我在本主题中的结尾,以确认什么是命名表的“最佳实践”)
在阅读了这篇文章中的所有争论之后,我得出了一个结论:
不管每个人最喜欢的口味是什么,我都喜欢我的蜂蜜煎饼。但如果我为其他人做饭,我会尝试为他们提供他们喜欢的东西。