表命名：下划线与驼峰式？命名空间？单数还是复数？

89

我一直在阅读有关StackOverflow的几个问题/答案，试图找到“最佳”（或者应该说必须接受的方式）来命名数据库中的表。

大多数开发人员倾向于根据需要数据库的语言（JAVA，.NET，PHP等）来命名表。但是我只是觉得这是不对的。

到目前为止，我一直在命名表格的方式是：

doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents

我担心的是：

易读性
快速识别表格的来源（医生||患者）
易于理解，防止混淆。

我想阅读有关命名约定的任何意见。谢谢。

database database-design

— 马里奥·里卡德
source

180

保持一致远比您使用哪种特定方案重要。

— 大卫·奥尼尔
source

21

换句话说，是的，做得很好，您已经确定了一些一致的方案。继续吧！

— Phil H

3

+1评论。另外，请注意当前的命名方案PascalCase更好，特别是如果您不对SQL查询使用Aliases。这样，您可以在表列名称上使用camelcase，在表名称上使用Pascal Case。

— MarioRicalde

3

表名称的Pascal / camel大小写可能会导致某些问题。每个表在文件系统中都有一个文件，其中一些不区分大小写（例如OSX）。

— ismriv

2

@ismriv只有在您不一致的情况下才是问题，如果您始终以相同的大小写引用表/视图/列，那么您应该不会有任何问题，编写这些名称时不要偷懒会为您带来很多好处以后阅读时的优势。对表使用PascalCase，对列使用camelCase有助于一眼识别名称的类型，并且还可以模仿常见的面向对象的约定。

— TWiStErRob

我完全同意，一致性是关键，但是这是一个老问题和使用像红移和雪花更新的数据库平台的人们，默认要么全部大写或小写标识，我想补充一点，是考虑比较重要的一开始就命名约定。在这些平台上选择使用诸如Camel Case之类的命名约定可能会在以后给您带来一些不必要的麻烦，例如，您将始终需要使用带引号的标识符，并且对象名称解析可能会产生意外的结果。

— 内森·格里菲思

22

我通常使用PascalCase，并且实体是单数的：

DoctorMain
DoctorProfile
DoctorPatient

它模仿了我的应用程序中类的命名约定，使所有内容都保持整洁，干净，一致且易于理解。

— 贾斯汀·尼斯纳（Justin Niessner）
source

3

是的，是的。今天早上我有点雾。进行编辑...谢谢。

— 贾斯汀·尼斯纳

3

也称为“ CapitalCase”。

— corsiKa

3

在我30年的工作经验中，我从未听说过它叫做“ CapitalCase”。我听说它最常被称为“骆驼皮”，而“帕斯卡皮”则是最近才被使用的。我来这里是为了了解为什么人们似乎在历史上对大小写不敏感的情况下使用SQL的驼峰式大小写。我当然不想落后于时代。

— Sinthia V

@SinthiaV我不了解其他人，但是在我们的情况下，因为我们使用的是JS ORM（遗憾的是），选项是1）通过在db中使用camelCase打破常规2）通过在JS中使用snake_case打破常规3）映射camelCase在JS中到db中的snake_case。我们最初没有过多的想法就决定在数据库中使用camelCase，虽然还算不错，但是引用所有内容都有些麻烦。

— 安迪

@SinthiaV无用评论，这可能是在实际的SO问题的上下文中，PascalCase与camelCase不同。PascalCase将每个单词的首字母大写（至关重要的是包括第一个字母），而camelCase仅将第一个单词后的大写字母大写。延伸阅读：medium.com/better-programming/...

— 奇怪之处

11

SQL支持不区分大小写的性质Underscores_Scheme。但是，现代软件支持任何种类的命名方案。但有时也会出现一些讨厌的错误，错误或人为因素会导致UPPERCASINGEVERYTHING使那些，谁选择都Pascal_Case和Underscore_Case在好地方所有他们的神经机制活。

— TerR0Q
source

10

以上大部分内容的汇总：

不要依赖数据库中的大小写
不要考虑名称的大小写或分隔符部分-只是单词
请使用您语言标准的分隔符或大小写

然后，您可以轻松地在环境之间转换（甚至自动）名称。

但是我还要补充一点：从应用程序中的类移动到数据库中的表时，您可能还会发现其他因素：数据库对象具有视图，触发器，存储的proc，索引，约束等-也需要名字。因此，例如，您可能会发现自己仅通过视图访问表，这些视图通常只是一个简单的“ select * from foo”。可以将它们标识为仅带有后缀'_v'的表名，也可以将它们放在其他模式中。如此简单的抽象层的目的在于，可以在必要时对其进行扩展，以允许更改一个环境以避免影响另一个环境。这不会破坏上面的命名建议-还要说明几件事。

— 肯法
source

8

我使用下划线。几年前，我做了一个Oracle项目，看来Oracle强迫我所有的对象名都使用大写字母，这对任何大小写方案都是一种打击。我不是Oracle专家，所以也许有一种我不知道的解决方法，但这使我使用了下划线，而且我从未回过头。

— 射线
source

2

在11g及更高版本中，如果表名用双引号引起来，则似乎保留了大小写。将其放在此处以供将来参考。我肯定知道Postgres也这样做，其他数据库引擎可能不会。

— John O

8

由于该问题并非特定于特定的平台或数据库引擎，因此，为了最大程度地实现可移植性，我必须始终使用小写的表名。

/ [a-z _] [a-z0-9 _] * /实际上是唯一可以在不同平台之间无缝转换的名称模式。小写字母数字和下划线将始终保持一致。

如其他地方所述，关系（表）名称应为单数形式：http : //www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html

— 富人
source

我同意-与Pascal或骆驼套管相比，下划线问题最少。特别是当您命名到模型时，最后到dto和frontend。

— Saulius

6

我倾向于同意那些说这取决于您使用的语言约定的人（例如，C＃的PascalCase和Ruby的snake_case）。

但是，请不要使用camelCase。

— 马克·雷德尔
source

2

艾达（Ada）：Pascal_Case_With_Underscores

— 2014年

6

当您想使用两种具有不同命名约定的不同语言访问同一张表时，这没有任何意义。

— Daniel W.

5

在阅读了许多其他意见之后，我认为使用语言的命名约定非常重要，仅当您（并将成为）应用程序的唯一开发人员时，一致性比命名约定更重要。如果您希望具有可读性（这非常重要），则最好为每种语言使用命名约定。例如，在MySQL中，我不建议使用CamelCase，因为并非所有平台都区分大小写。因此，这里的下划线会更好。

— 弗拉德·曼努埃尔·穆兰
source

1

绝对同意！！！尤其是在Windows上运行MySql时，一切都从camelCase变为camelcase。因此，拥有蛇皮盒会更好。关于Modern software however supports any kind of naming scheme您，您也没有任何保证，yop会为最新版本的soft编写代码。尤其是对于数据库而言，考虑到回归成本时，版本更新并非易事。

— 樱桃

2

这是我的五分钱。我得出的结论是，如果将来自不同供应商的数据库用于一个项目，则有两种最佳方法：

使用下划线。
使用带引号的驼峰式保护套。

原因是某些数据库会将所有字符都转换为大写，而某些则转换为小写。因此，如果有myTable，它将成为您MYTABLE或mytable与DB合作的时机。

— 帕维尔
source

1

不幸的是，这个问题没有“最佳”答案。正如@David所说，一致性远比命名约定重要。

— 凯恩
source

1

分离单词的方式差异很大，因此您必须选择更好的方式；但与此同时，似乎几乎已经达成共识，表名应为单数。

— 哈维尔
source

1

命名约定存在于一种语言的范围内，并且不同的语言具有不同的命名约定。

默认情况下，SQL不区分大小写；因此，snake_case是一种广泛使用的约定。SQL还支持定界标识符。因此，可以选择混合大小写，例如camelCase（Java，其中字段==列）或PascalCase（C＃，其中表==类和列==字段）。如果您的数据库引擎不支持SQL标准，那就是它的问题。您可以决定使用该引擎，也可以选择其他引擎。（为什么C＃不得不与众不同，这对于同时使用这两种代码的我们来说是一个令人沮丧的问题。）

如果打算只在服务和应用程序中使用一种语言，请在所有层使用该语言的约定。否则，请在使用该语言的领域中使用该语言中使用最广泛的约定。

— 克里斯·哥利奇
source