表命名：下划线与Camelcase？命名空间？奇异与多元？

Posted 2021-04-05

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

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

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

doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents 

我关心的是：

• 易读性
• 快速识别表格所在的模块（医生||患者）
• 易于理解，以防止混淆。

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

答案

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

另一答案

如何分离单词有很多变化，所以你必须选择你喜欢的任何东西;但与此同时，似乎有一个共识，即表名应该是单数。

另一答案

这是我的五美分。我得出结论，如果来自不同供应商的DB用于一个项目，有两种最佳方式：

1. 使用下划线。
2. 使用带引号的驼峰案例。

原因是某些数据库会将所有字符转换为大写，有些转换为小写。所以，如果你有myTable，当你使用DB时它会变成MYTABLE或mytable。

另一答案

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

DoctorMain
DoctorProfile
DoctorPatient

它模仿我的应用程序中的类的命名约定，使每个人都能保持整洁，干净，一致且易于理解。

另一答案

SQL不区分大小写的本质支持Underscores_Scheme。然而，现代软件支持任何类型的命名方案。然而，有时一些讨厌的错误，错误或人为因素可以导致UPPERCASINGEVERYTHING，以便那些选择Pascal_Case和Underscore_Case计划的人生活在他们所有的神经的好地方。

另一答案

以上大部分内容的汇总：

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

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

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

另一答案

我使用下划线。几年前我做了一个Oracle项目，看起来Oracle强迫我所有的对象名称都是大写的，这会打击任何套管方案。我不是一个真正的甲骨文家伙，所以也许有一种解决方法，我不知道，但它让我使用下划线，我从来没有回去过。

另一答案

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

但是，从来没有骆驼过。

另一答案

由于问题不是特定于特定平台或数据库引擎，我必须说最大程度的可移植性，您应该始终使用小写表名。

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

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

另一答案

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

另一答案

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