如果我们查看MS SQL Server的系统表，Microsoft指定的表名是复数。

Oracle的系统表以单数形式命名。尽管其中有几个是复数。Oracle建议用户定义的表名使用复数。他们推荐一件事而遵循另一件事，这没有多大意义。这两个软件巨头的架构师使用不同的约定来命名他们的表，这也没有多大意义。。。毕竟，这些家伙是什么。。。博士学位？

我记得在学术界，这项建议是独一无二的。

例如，当我们说：

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

也许b/c每个ID都是从特定的单行中选择的。。。？

我也会使用复数形式，对于前面提到的用户困境，我们确实采用了方括号方法。

我们这样做是为了在数据库体系结构和应用程序体系结构之间提供一致性，基本上理解为用户表是用户值的集合，就像代码工件中的用户集合是用户对象的集合一样。

让我们的数据团队和开发人员使用相同的概念语言（尽管不总是相同的对象名称），可以更容易地在他们之间传达想法。

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

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

我还喜欢将所有ID列命名为ID，而不是ChickenId或ChickenId（复数个家伙对此做什么？）。

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

如果我们查看MS SQL Server的系统表，Microsoft指定的表名是复数。

Oracle的系统表以单数形式命名。尽管其中有几个是复数。Oracle建议用户定义的表名使用复数。他们推荐一件事而遵循另一件事，这没有多大意义。这两个软件巨头的架构师使用不同的约定来命名他们的表，这也没有多大意义。。。毕竟，这些家伙是什么。。。博士学位？

我记得在学术界，这项建议是独一无二的。

例如，当我们说：

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

也许b/c每个ID都是从特定的单行中选择的。。。？

我通过将表命名为“雇员”（实际上是“雇员”）来解决同样的问题。我尽量避免与可能保留的单词发生冲突。即使是“用户”对我来说也很近。

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

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

实际一致性有时是最佳标准…：）

my2内容---