虽然很晚了，但我仍然想对列前缀发表我的意见

对于使用table_column(或tableColumn)列命名标准，似乎有两个主要的论据，都是基于列名本身在整个数据库中是唯一的这一事实:

1)你不需要一直在你的查询中指定表名和/或列别名

2)你可以很容易地在整个代码中搜索列名

我认为这两种观点都有缺陷。不使用前缀解决这两个问题很简单。以下是我的建议:

在SQL中始终使用表名。例如，总是用table。列而不是列。

它显然解决了2)你现在只需要搜索表。而不是table_column。

But I can hear you scream, how does it solve 1)? It was exactly about avoiding this. Yes, it was, but the solution was horribly flawed. Why? Well, the prefix solution boils down to: To avoid having to specify table.column when there's ambiguity, you name all your columns table_column! But this means you will from now on ALWAYS have to write the column name every time you specify a column. But if you have to do that anyways, what's the benefit over always explicitly writing table.column? Exactly, there is no benefit, it's the exact same number of characters to type.

编辑:是的，我知道用前缀命名列可以强制使用正确的用法，而我的方法依赖于程序员

表名:它应该是单数，因为它是一个表示真实世界对象的单数实体，而不是表示对象的单数实体。

列名:它应该是单数，只有这样它才表示它将持有一个原子值，并将确认归一化理论。然而，如果有n个相同类型的属性，那么它们应该以1,2，…作为后缀。n，等等。

表/列前缀:这是一个巨大的主题，将在后面讨论。

外壳:应该是驼色的

我的朋友Patrick Karcher，我请求你不要写任何可能冒犯别人的东西，就像你写的那样，“此外，外键必须在不同的表中一致命名。如果有人不这样做，殴打他应该是合法的。”我从来没有犯过这样的错误，我的朋友帕特里克，但我写一般。如果他们一起打算为此揍你呢?：）

基本数据库命名约定(和样式)(点击这里查看更详细的描述)

表名 选择简短、明确的名字，不要超过一两个单词 容易区分表 方便唯一字段名的命名以及查找和链接表 给表取单数名，而不是复数名(更新:我仍然同意这种惯例的原因，但大多数人真的喜欢复数表名，所以我的立场软化了)…请点击上面的链接

我的观点是:

1)不，表名应该是单数。

虽然对于简单的选择(select * from Orders)似乎有意义，但对于OO等效(Orders x = new Orders)则没有意义。

数据库中的表实际上是该实体的集合，当你使用set-logic时，它更有意义:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

最后一行，连接的实际逻辑，看起来与复数表名混淆。

我不确定是否总是使用别名(如Matt建议的那样)可以消除这种情况。

2)它们应该是单数，因为它们只拥有一种属性

3)如果列名有歧义(如上所述，它们都有一个名为[Key]的列)，表名(或其别名)永远不能很好地区分它们。您希望查询能够快速键入，并且简单-前缀会增加不必要的复杂性。

4)无论你想要什么，我都推荐CapitalCase

我不认为有任何一套绝对的指导方针。

只要你在应用程序或数据库中选择的是一致的，我不认为这真的很重要。

不。表应该以它所代表的实体命名。 Person，而不是persons是指记录所代表的人。 同样的事情。列FirstName真的不应该被称为FirstNames。这完全取决于你想用列表示什么。 不。 是的。为清晰起见。如果你需要像“FirstName”这样的列，大小写会让它更容易阅读。

好的。这是我的0.02美元

我也支持ISO/IEC 11179风格的命名约定，指出它们是指导方针而不是规定。

参见维基百科上的数据元素名称:

表是实体的集合，并遵循集合命名准则。理想情况下，使用一个集合名称。、人员。复数形式也是正确的:Employees。不正确的名称包括:Employee、tblEmployee和EmployeeTable。”

与往常一样，规则也有例外，例如，一个总是只有一行的表可能用一个奇异的名字更好，例如配置表。一致性是最重要的:检查你的购物是否有惯例，如果有，就遵守它;如果你不喜欢它，那就做一个商业案例来改变它，而不是做一个独行侠。