学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
当前回答
实际上,我一直认为使用多个表名是一种流行的习惯。到目前为止,我一直使用复数。
我可以理解单数表名的论点,但对我来说,复数表名更有意义。表名通常描述表包含的内容。在标准化数据库中,每个表都包含特定的数据集。每一行都是一个实体,表中包含许多实体。因此,表名的复数形式。
一张汽车表上会有汽车的名字,每一排都是一辆汽车。我承认,以table.field的方式指定表和字段是最好的做法,使用单一的表名更容易阅读。然而,在以下两个例子中,前者更有意义:
SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'
老实说,我将重新思考我在这件事上的立场,我将依赖于我正在开发的组织所使用的实际惯例。然而,我认为出于个人习惯,我将坚持使用复数表名。对我来说,这更有意义。
其他回答
我是单数表名的粉丝,因为它们使用CASE语法使我的ER图更容易阅读,但通过阅读这些响应,我感到它从未很好地被理解?我个人很喜欢它。这里有一个很好的概述,举例说明当你使用单数表名,在你的关系中添加动作动词,并为每一种关系形成好句子时,你的模型是多么可读。对于一个20表的数据库来说,这有点过分了,但是如果您有一个包含数百个表的数据库,并且设计复杂,如果没有一个可读性好的图表,您的开发人员将如何理解它?
http://www.aisintl.com/case/method.html
至于表和视图的前缀,我绝对讨厌这种做法。在给一个人提供可能不好的信息之前,不要给他任何信息。任何浏览数据库查找对象的人都可以很容易地将表与视图区分开来,但如果我有一个名为tblUsers的表,出于某种原因,我决定在将来将其重组为两个表,并使用一个视图统一它们,以防破坏旧代码,那么我现在有一个名称为tblUser的视图。此时,我只剩下两个没有吸引力的选项:留下一个带有tbl前缀的视图,这可能会让一些开发人员感到困惑,或者强制重写另一个层(中间层或应用程序),以引用我的新结构或名称viewUsers。这否定了IMHO视图的大部分价值。
举个简单的例子:
SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"
vs.
SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"
后者中的SQL比前者听起来更奇怪。
我投票支持单数。
我坚持表名和任何编程实体使用单数。
原因是什么?事实上,英语中有不规则的复数形式,如mouse⇒ 老鼠和绵羊⇒ 羊然后,如果我需要收集,我只需要使用老鼠或绵羊,然后继续。
这确实有助于多元性脱颖而出,而且我可以通过编程轻松地确定这些东西的集合是什么样子的。
所以,我的规则是:所有事物都是单数,所有事物的集合都是单数的,并加上s。也有助于ORM。
我个人更喜欢用复数来表示一个集合,这对我的关系思维来说“听起来”更好。
此时此刻,我正使用单数名称为我的公司定义一个数据模型,因为大多数工作人员都觉得它更舒服。有时候,你只需要让每个人的生活更轻松,而不是强加你的个人喜好。(这就是我在本主题中的结尾,以确认什么是命名表的“最佳实践”)
在阅读了这篇文章中的所有争论之后,我得出了一个结论:
不管每个人最喜欢的口味是什么,我都喜欢我的蜂蜜煎饼。但如果我为其他人做饭,我会尝试为他们提供他们喜欢的东西。
我一直认为那是一个愚蠢的惯例。我使用多个表名。
(我相信这一策略背后的原因是,它使ORM代码生成器更容易生成对象和集合类,因为从单数名称生成复数名称比从单数名称中生成复数名称更容易)