学术界认为,表名应该是存储其属性的实体的单数。

我不喜欢任何需要在名称周围加方括号的T-SQL,但我已经将一个Users表重命名为单数,这永远意味着使用该表的人有时不得不使用括号。

我的直觉是,保持单数更正确,但我的直觉也是,括号表示不需要的东西,比如列名中有空格等。

我该留下还是该走?


当前回答

两个网站都有不同的论文,我认为你只需要选择你的一方。就我个人而言,我更喜欢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

其他回答

我不喜欢复数表名,因为英语中的一些名词是不可数的(水、汤、现金),或者当你使其可数时,其含义会发生变化(鸡vs鸡;肉vs鸟)。我也不喜欢使用表名或列名的缩写,因为这样做会给已经陡峭的学习曲线增加额外的斜率。

具有讽刺意味的是,我可能会将User作为一个例外,并将其称为User,因为User(Transac SQL),因为如果不需要的话,我也不喜欢在表周围使用括号。

我还喜欢将所有ID列命名为ID,而不是ChickenId或ChickenId(复数个家伙对此做什么?)。

这一切都是因为我对数据库系统没有适当的尊重,我只是在重新应用OO命名约定中的一个技巧,比如Java的习惯和懒惰。我希望有更好的IDE支持复杂的SQL。

这可能有点多余,但我建议谨慎行事。重命名表不一定是坏事,但标准化就是这样;一个标准——这个数据库可能已经被“标准化”了,无论多么糟糕:)——我建议一致性是一个更好的目标,因为这个数据库已经存在,而且它可能不仅仅由两个表组成。

除非您能够标准化整个数据库,或者至少计划为此目的而努力,否则我怀疑表名只是冰山一角,专注于手头的任务,忍受命名不好的对象的痛苦,可能符合您的最大利益--

实际一致性有时是最佳标准…:)

my2内容---

如果你去那里会有麻烦,但如果你留下来,麻烦就会加倍。

我宁愿违背一些假定的非复数命名惯例,也不愿用可能是保留词的名称来命名我的表。

表的SQL定义实际上是表的一个潜在行的定义,而不是集合。因此,该定义中使用的名称必须指定行的类型,而不是集合的名称。那些喜欢复数的人,因为它在他们的英语语句中读起来很好,他们需要开始更逻辑地思考,并查看实际使用表所涉及的所有逻辑和编程代码。这些注释中提到了使用单数表名的几个很好的理由。其中包括不使用多个表名的充分理由。“好好读书”根本不应该是任何理由,尤其是因为有些人可能会以不同的方式来理解这个想法。

如果您使用Zend Framework(PHP)等特定框架,那么明智的做法是表类使用复数,行类使用单数。

因此,假设您创建了一个表对象$users=newUsers(),并将行类声明为User,那么您也可以调用newUser()。

现在,如果对表名使用单数,则必须执行类似于newUserTable()的操作,其中的行是newUserRow()。对我来说,这看起来比为表设置对象Users()和为行设置User()对象更笨拙。