oop – 在PostgreSQL标识符中的下划线或camelCase,当编程语言使用camelCase?

前端之家收集整理的这篇文章主要介绍了oop – 在PostgreSQL标识符中的下划线或camelCase,当编程语言使用camelCase?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
这一直困扰我一段时间,我不能得到一个感觉正确的解决方案…

给出一种OO语言,其中对象属性的通常的命名约定是camelCased,并且这样一个示例对象:

{
    id: 667,firstName: "Vladimir",lastName: "Horowitz",canPlayPiano: true
}

在Postgresql表中如何建模这个结构?

有三个主要选择:

>无引号的camelCase列名
>引用camelCase列名
>带有下划线的无引号(小写)名称

它们各有缺点:

>未引用的标识符会自动折叠成小写。这意味着您可以使用canPlayPiano列创建表,但混合大小写永远不会到达数据库。当您检查表格时,列将始终显示为canplaypiano – 在psql,pgadmin,解释结果,错误消息,一切。
>引用的标识符保留他们的情况,但一旦你创建它们,你将始终引用它们。 IOW,如果您创建一个带有“canPlayPiano”列的表,则SELECT canPlayPiano …将失败。这给所有的sql语句增加了不必要的噪音。
>带有下划线的小写名称是明确的,但它们不能很好地映射到应用程序语言使用的名称。您必须记住使用不同的名称进行存储(can_play_piano)和代码(canPlayPiano)。它还可以防止某些类型的代码自动化,其中属性和DB列需要命名相同。

所以我被困在一个岩石和一个困难的地方(和一块大石头;有三个选择)。无论我做什么,有一部分会感到尴尬。在过去的10年左右,我一直在使用选项3,但我一直希望会有更好的解决方案。

我很感谢你可能有任何建议。

PS:我确实意识到案例折叠和引用需求来自于sql标准,或者Postgresql适应标准。我知道它是如何工作的我对关于最佳实践的建议更感兴趣,而不是关于PG如何处理标识符的说明。

鉴于Postgresql使用不区分大小写的标识符与下划线,您应该更改应用程序中的所有标识符以执行相同操作吗?显然不是那么你为什么认为相反是合理的选择?

Postgresql的惯例是通过标准合规性和用户的长期体验结合起来的。坚持下去。

如果在列名和标识符之间进行翻译很繁琐,请让计算机做到这一点 – 他们擅长这样的事情。我猜测几乎所有的900万数据库抽象库都可以做到这一点。如果您有动态语言,则会将所有两行代码用于将列名交换为CamelCase中的标识符。

猜你在找的Postgre SQL相关文章