表命名: 下划线与骆驼? 名称空间? 单数与复数？

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

大多数开发人员倾向于根据需要数据库的语言(JAVA，。NET、 PHP 等)。但是我觉得这样不对。

我现在给桌子命名的方法是这样的:

doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents

我担心的是:

  • 易读性
  • 快速识别模块表是从(医生 | | 病人)
  • Easy to understand, to prevent confusions.

我想阅读任何关于命名约定的意见。 Thank you.

123020 次浏览
小开

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

DoctorMain
DoctorProfile
DoctorPatient

It mimics the naming conventions for classes in my application keeping everything pretty neat, clean, 始终如一, and easy to understand for everybody.

小开
最佳答案

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

小开

不幸的是，这个问题没有“最佳”答案。正如@大卫所说，一致性远比变数命名原则重要。

小开

我使用下划线。几年前我做过一个 Oracle 项目，看起来 Oracle 把我所有的对象名都改成了大写，这有点搞砸了所有的套装方案。我不是一个真正的甲骨文的人，所以也许有一个方法，我不知道这一点，但它使我使用下划线，我从来没有回去。

小开

I tend to agree with the people who say it depends on the conventions of language you're using (e.g. PascalCase for C# and snake_case for Ruby).

Never camelCase, though.

小开

关于如何分隔单词，存在很大的差异，因此你必须选择你更喜欢的任何单词; 但同时，似乎大家都认为表名应该是单数。

小开

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

小开

An aggregation of most of the above:

  • 不要依赖数据库中的案例
  • 不要把大小写或分隔符看作是名称的一部分——只看单词
  • 使用任何分隔符或大小写作为你的语言的标准

然后您就可以轻松地在不同环境之间翻译(甚至自动翻译)名称。

但是我要补充另一个考虑因素: 当你从应用中的一个类移动到数据库中的一个表时，你可能会发现还有其他因素: 数据库对象有视图、触发器、存储过程、索引、约束等等——这些也需要名称。因此，例如，您可能发现自己只能通过通常只是简单的“ select * from foo”视图访问表。它们可以被标识为只有’_ v’后缀的表名，或者您可以将它们放在不同的模式中。这个简单抽象层的目的是在有需要时可以扩展，以容许在一个环境中发生变化，从而避免影响另一个环境。这不会打破上面的命名建议-只是多了一些事情要考虑。

小开

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

小开

由于这个问题不是特定于特定平台或 DB 引擎的，因此我必须说，为了最大限度地实现可移植性，应该始终使用小写表名。

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

正如在其他地方提到的，关系(表)名称应该是单数: http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html

小开

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

  1. 使用下划线。
  2. 使用带引号的驼峰大小写。

原因是有些数据库将所有字符转换为大写，有些数据库将所有字符转换为小写。因此，如果你有 myTable，它将成为 MYTABLE或 mytable时，你将与数据库。

小开

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

默认情况下，SQL 是不区分大小写的; 因此，Snake _ case 是一个广泛使用的约定。SQL 还支持带分隔符的标识符; 因此，在一个选项中混合使用大小写，比如 camelCase (Java，其中字段 = = 字段)或 PascalCase (C # ，其中表 = = 类和列 = = 字段)。如果数据库引擎不支持 SQL 标准，那就是它的问题所在。你可以决定接受这个事实，或者选择其他的引擎。(为什么 C # 必须与众不同，对于我们这些同时使用两种语言编码的人来说，这是一个令人恼火的问题。)

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

小开

C # 接近

单数/复数

  • 如果行中的记录只包含1个值，则为单数。
  • 如果是数组，那么使用复数。当你提到这些元素的时候，它也是非常有意义的。例如，您的数组列包含访问次数最多的地点: 伦敦、纽约、伯拉第斯拉瓦

然后:

foreach(var mostVisitedLocation in MostVisitedLocations){
//go through each array element
}

弹壳

表名的 PascalCase 和列的 camelCase 对我来说最有意义。但对我来说。NET 5当我把 json 对象保存在 dbs 中，使用 camelCase 中的 json 对象名称时，System.Text.Json无法将其反序列化为对象。因为您的模型必须是公共的，并且公共属性是 PascalCase。因此，将表列(骆驼箱)和 json 对象名(camelCase)映射到这些属性可能会导致错误(因为映射是区分大小写的)。 顺便说一下，对于 NeftonsoftJson，这个问题是不存在的。

所以我在应用程序的结尾写道:

表: App. Admin，App. Price，UserData. Account

栏目: Id，Price，IsOnline。

小开

根据用例提出2条建议:

  1. 单数表名。

虽然我曾经相信表名的复数形式，但是我发现在实践中，除了人类思维将表作为集合来考虑之外，它几乎没有什么好处。
当对表名进行单数化时，您可以在头脑中默默地将-table 添加到单数表名中，然后这一切就又变得有意义了。

SELECT username FROM UserTable

听起来很自然

SELECT username FROM UsersTable

但是把每张桌子都修好只是一种浪费。

单一化表名的实际实际论证:

人的复数是什么: 人还是人？
这还是可以的。
但是你喜欢有后缀状态的表吗? 状态？
真糟糕，抱歉。 将状态表单一化，而将其他表复数化，很容易造成人为错误。

  1. PascalCasing + 下划线约定。

给定表 User、 Role和多对多表 User_Role。
考虑到下划线大小写 user_role是可疑的，当所有的表名都使用下划线每缺省。 user_role是一个包含用户角色的表吗? 在这种情况下，它不是，它是一个连接表。

在决定表名约定时，我认为有必要放弃个人偏好，并考虑到现实生活中问题的实际考虑，以尽量减少可疑情况的发生。
正如许多答案和观点所表明的那样，无论你的个人观点是什么，不同的人会有不同的想法，你不会是唯一一个在数据库上工作的人，尽管你是建立数据库的人(除非你这样做，在这种情况下你只是在帮助你自己)。
因此，当你过去的决定受到质疑时，有实际的论证是有用的(实际的意义上，它是否有助于我未来的同事避免可疑的情况)。


提交答案