当编程语言使用 camelCase 时，PostgreSQL 标识符中的下划线或 camelCase？

这已经困扰我一段时间了，我不能达成一个解决方案，感觉 对..。

给定一个面向对象语言，其中对象属性的通常变数命名原则是 camelcsed，并且给出一个像下面这样的示例对象:

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

我应该如何在 PostgreSQL 表中建模这个结构？

主要有三种选择:

  1. 未引用的 camelCase 列名
  2. 引用 camelCase 列名
  3. 带下划线的非引号(小写)名称

它们各有缺点:

  1. 无引号的标识符自动折叠成小写。这意味着您可以创建一个包含 canPlayPiano列的表，但是混合大小写永远不会到达数据库。当您检查表时，该列总是以 canplaypiano的形式显示——在 psql、 pgadmin 中，解释结果、错误消息等等。

  2. 引用标识符保留它们的大小写，但是一旦像这样创建它们，一直都是就必须引用它们。IOW，如果创建一个包含 "canPlayPiano"列的表，则 SELECT canPlayPiano ...将失败。这会给所有 SQL 语句添加大量不必要的噪音。

  3. 带下划线的小写名称是明确的，但是它们不能很好地映射到应用程序语言所使用的名称。您必须记住对存储(can_play_piano)和代码(canPlayPiano)使用不同的名称。它还可以防止某些类型的代码自动化，其中属性和 DB 列的名称必须相同。

所以我被夹在一块石头和一块硬石头之间(还有一块大石头，有三种选择)。不管我做什么，总会有些尴尬。在过去10年左右的时间里，我一直在使用选项3，但我一直希望有一个更好的解决方案。

我很感激你的建议。

PS: 我确实知道折叠大小写和引号的需求来自哪里—— SQL 标准，或者更确切地说是 PostgreSQL 对该标准的改编。我知道它是如何工作的; 我更感兴趣的是关于最佳实践的建议，而不是关于 PG 如何处理标识符的解释。

40939 次浏览
小开
最佳答案

考虑到 PostgreSQL 使用带下划线的不区分大小写的标识符，是否应该更改应用程序中的所有标识符以执行相同操作？显然不是。那么为什么你认为相反的选择是合理的呢？

PostgreSQL 中的约定是通过遵循标准和用户的长期经验而实现的。坚持下去。

如果在列名和标识符之间进行翻译变得乏味，那就让计算机来做——它们擅长这样的事情。我猜几乎所有的900万个数据库抽象库都可以做到这一点。如果使用动态语言，则需要两行代码才能将 CamelCase 中的列名转换为标识符。

小开

如果 PostgreSQL中的列使用 underscores，则可以使用别名，但使用 双引号。

例如:

SELECT my_column as "myColumn" from table;
小开

我知道这有点晚了，但是对于一些简单的动态翻译，你可以编写一个小的帮助函数，就像这样存在于你的代码中:

函数 FormatObjecForDb (srcObj){

const newObj = {};


Object.keys(srcObj).forEach(key => newObj[key.toLowerCase()] = srcObj[key]);


return newObj;

}

Export const formatObjForDb = FormatObjForDb;


提交答案