学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
学术界认为,表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。
我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。
我该留下还是该走?
当前回答
可能的替代方案:
重命名表SystemUser使用括号保留多个表名。
IMO使用括号从技术上来说是最安全的方法,尽管它有点麻烦。IMO是一个6个,另一个6打,您的解决方案实际上只是归结为个人/团队偏好。
其他回答
实际上,我一直认为使用多个表名是一种流行的习惯。到目前为止,我一直使用复数。
我可以理解单数表名的论点,但对我来说,复数表名更有意义。表名通常描述表包含的内容。在标准化数据库中,每个表都包含特定的数据集。每一行都是一个实体,表中包含许多实体。因此,表名的复数形式。
一张汽车表上会有汽车的名字,每一排都是一辆汽车。我承认,以table.field的方式指定表和字段是最好的做法,使用单一的表名更容易阅读。然而,在以下两个例子中,前者更有意义:
SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'
老实说,我将重新思考我在这件事上的立场,我将依赖于我正在开发的组织所使用的实际惯例。然而,我认为出于个人习惯,我将坚持使用复数表名。对我来说,这更有意义。
我也会使用复数形式,对于前面提到的用户困境,我们确实采用了方括号方法。
我们这样做是为了在数据库体系结构和应用程序体系结构之间提供一致性,基本上理解为用户表是用户值的集合,就像代码工件中的用户集合是用户对象的集合一样。
让我们的数据团队和开发人员使用相同的概念语言(尽管不总是相同的对象名称),可以更容易地在他们之间传达想法。
我通过将表命名为“雇员”(实际上是“雇员”)来解决同样的问题。我尽量避免与可能保留的单词发生冲突。即使是“用户”对我来说也很近。
举个简单的例子:
SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"
vs.
SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"
后者中的SQL比前者听起来更奇怪。
我投票支持单数。
我只对拼写相同的表名使用名词,无论是单数还是复数:
驼鹿鱼鹿飞机你内裤短裤眼镜剪刀种孩子