66

这一直困扰着我一段时间，我无法找到一个感觉正确的解决方案......

给定一种 OO 语言，其中对象属性的通常命名约定是驼峰式命名，以及这样的示例对象：

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

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

有三个主要选项：

  1. 不带引号的 camelCase 列名
  2. 引用的 camelCase 列名
  3. 带下划线的不带引号（小写）的名称

它们各有缺点：

  1. 不带引号的标识符会自动折叠为小写。这意味着您可以创建带有canPlayPiano列的表，但混合大小写永远不会到达数据库。当您检查表时，该列将始终显示为canplaypiano- 在 psql、pgadmin、解释结果、错误消息等所有内容中。

  2. 带引号的标识符保留它们的大小写，但是一旦您像这样创建它们，您将始终必须引用它们。IOW，如果您创建带有"canPlayPiano"列的表，则 aSELECT canPlayPiano ...将失败。这给所有 SQL 语句增加了很多不必要的噪音。

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

所以我被夹在一块石头和一块坚硬的地方（还有一块大石头；有三种选择）之间。不管我做什么，总有一部分会让人觉得尴尬。在过去 10 年左右的时间里，我一直在使用选项 3，但我一直希望会有更好的解决方案。

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

PS：我确实意识到大小写折叠和引号需求的来源 - SQL 标准，或者更确切地说是 PostgreSQL 对标准的改编。我知道它是如何工作的；我对最佳实践的建议比对 PG 如何处理标识符的解释更感兴趣。

4

3 回答 3

45

如果您的列PostgreSQL带有underscores，您可以使用别名但带有双引号。

例子 ：

SELECT my_column as "myColumn" from table;
于 2013-12-10T10:03:44.230 回答
30

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

PostgreSQL 中的约定是通过标准合规性和用户的长期经验来实现的。坚持下去。

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

于 2012-06-30T05:38:18.647 回答
1

我知道这已经很晚了，但是对于一些很容易即时翻译的东西，你可以编写一个小的帮助函数，它会存在于你的代码中：

函数 FormatObjForDb(srcObj){

const newObj = {};

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

return newObj;

}

导出常量 formatObjForDb = FormatObjForDb;

于 2020-04-17T18:04:57.867 回答