我一直在阅读有关 StackOverflow 的几个问题/答案，试图找到“最好的”，或者我应该说必须接受的方式来命名数据库上的表。
大多数开发人员倾向于根据需要数据库的语言（JAVA、.NET、PHP 等）来命名表。但是我只是觉得这不对。
到目前为止，我一直在命名表的方式是：
doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents
我担心的是：
我想了解有关命名约定的任何意见。 谢谢。
【问题讨论】：
保持一致远比您使用的特定方案重要得多。
【讨论】：
我通常使用 PascalCase 并且实体是单数的：
DoctorMain
DoctorProfile
DoctorPatient
它模仿了我的应用程序中类的命名约定，使所有内容都非常整洁、干净、一致，并且每个人都易于理解。
【讨论】：
SQL 不区分大小写的特性支持Underscores_Scheme。然而，现代软件支持任何类型的命名方案。然而，有时一些讨厌的错误、错误或人为因素可能会导致UPPERCASINGEVERYTHING，因此那些同时选择Pascal_Case 和Underscore_Case 方案的人可以放心地生活。
【讨论】：
以上大部分内容的集合：
然后您可以轻松地在环境之间翻译（甚至是自动）名称。
但我还要补充一点：当您从应用程序中的类移动到数据库中的表时，您可能会发现还有其他因素：数据库对象具有视图、触发器、存储过程、索引、约束、等等 - 这也需要名字。例如，您可能会发现自己只能通过通常只是简单的“select * from foo”的视图访问表。这些可能被标识为仅带有“_v”后缀的表名，或者您可以将它们放在不同的模式中。这样一个简单的抽象层的目的是可以在必要时对其进行扩展，以允许在一个环境中进行更改以避免影响另一个环境。这不会破坏上述命名建议 - 只是需要考虑一些其他事项。
【讨论】：
由于该问题并非特定于特定平台或数据库引擎，因此我必须说，为了最大限度地提高可移植性，您应该始终使用小写的表名。
/[a-z_][a-z0-9_]*/ 确实是唯一可以在不同平台之间无缝转换的名称模式。小写字母数字+下划线将始终保持一致。
正如其他地方提到的，关系（表）名称应该是单数：http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html
【讨论】：
我使用下划线。几年前我做了一个甲骨文项目，甲骨文似乎强迫我所有的对象名都大写，这对任何大小写方案都是不利的。我不是一个真正的 Oracle 人，所以也许有一种我不知道的解决方法，但它让我使用了下划线，我再也没有回去过。
【讨论】：
我倾向于同意那些说这取决于您使用的语言约定的人的观点（例如 C# 的 PascalCase 和 Ruby 的蛇形大小写）。
不过，从不使用驼峰命名法。
【讨论】：
在阅读了很多其他意见后，我认为使用语言的命名约定非常重要，只有当您是（并且将成为）应用程序的唯一开发人员时，一致性才比命名约定更重要。如果您想要可读性（这非常重要），您最好使用每种语言的命名约定。例如，在 MySQL 中，我不建议使用 CamelCase，因为并非所有平台都区分大小写。所以这里下划线更好。
【讨论】：
camelCase 变为camelcase。所以有蛇盒要好得多。另外关于Modern software however supports any kind of naming scheme，你没有任何保证你会为最新版本的软件编写代码。特别是对于数据库 - 当您考虑回归成本时，版本更新并非易事。
这是我的五分钱。我得出的结论是，如果将来自不同供应商的数据库用于一个项目，则有两种最佳方法：
原因是某些数据库会将所有字符转换为大写，而另一些则转换为小写。因此，如果您有 myTable，当您使用 DB 时，它将变为 MYTABLE 或 mytable。
【讨论】：
命名约定存在于一种语言的范围内，不同的语言有不同的命名约定。
SQL 默认不区分大小写；因此，snake_case 是一种广泛使用的约定。 SQL 还支持分隔标识符；因此，在一个选项中混合大小写，例如 camelCase（Java，其中字段 == 列）或 PascalCase（C#，其中表 == 类和列 == 字段）。如果您的数据库引擎不能支持 SQL 标准，那就是它的问题。您可以决定接受它或选择其他引擎。 （为什么 C# 必须有所不同，这对于我们这些同时使用这两种代码的人来说是一个恶化点。）
如果您打算在您的服务和应用程序中只使用一种语言，请在所有层使用该语言的约定。否则，请使用该语言所在领域中使用最广泛的语言约定。
【讨论】：
很遗憾，这个问题没有“最佳”答案。正如@David 所说，一致性远比命名约定重要。
【讨论】：
如何分隔单词有很大的不同，所以你必须选择你更喜欢的；但与此同时，似乎几乎一致认为表名应该是单数。
【讨论】：
单数/复数
然后：
foreach(var mostVisitedLocation in MostVisitedLocations){
//go through each array element
}
外壳
对我来说，表名的 PascalCase 和列的 camelCase 最有意义。但是在我的.NET 5 中，当我将json 对象保存在dbs 中时，使用camelCase 中的json 对象名称，System.Text.Json 无法将其反序列化为对象。因为您的模型必须是公共的并且公共属性是 PascalCase。因此，将表列（camelCase）和 json 对象名称（camelCase）映射到这些属性可能会导致错误（因为映射区分大小写）。 顺便说一句，NeftonsoftJson 不存在这个问题。
所以我结束了应用程序：
表格： App.Admin、App.Pricing、UserData.Account
列： Id、Price、IsOnline。
【讨论】：
2 个基于用例的建议：
虽然我曾经一度相信表名的复数形式，但我在实践中发现，除了人类思维将表作为集合来思考之外，它几乎没有任何好处。
将表名单数化时，您可以在脑海中默默地将 -table 添加到单数表名中，然后一切都变得有意义了。
SELECT username FROM UserTable
听起来比
更自然SELECT username FROM UsersTable
但是用后修复每张桌子只是一种浪费。
单数化表名的实际论证：
人的复数是什么：人还是人？
这还可以。
但是你喜欢带有 postfix -status 的表吗？状态？
太烂了，对不起。
将状态表单数化，而将其他表复数化，很容易无意中犯人为错误。
给定表 User、Role 和多对多表 User_Role。
当所有表名默认使用下划线时，考虑下划线大小写 user_role 是可疑的。
user_role 是包含用户角色的表吗？在这种情况下它不是，它是一个连接表。
在决定表名约定时，我认为放弃个人偏好并考虑现实生活问题的实际考虑是有用的，以尽量减少可疑情况的发生。
正如许多答案和意见所表明的那样，无论您的个人意见是什么，不同的人都有不同的想法，尽管您是建立数据库的人，但您不会是唯一一个在数据库上工作的人（除非您这样做，在这种情况下您只是帮助自己）。
因此，当你过去的决定受到质疑时，进行实际的论证（从某种意义上说是实用的，它是否有助于我未来的同事避免可疑情况）很有用。
【讨论】：