Isso tem me incomodado há algum tempo, e não consigo chegar a uma solução que pareçacerto...

Dada uma linguagem OO em que a convenção de nomenclatura usual para propriedades de objeto é camelCased e um exemplo de objeto como este:

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

Como devo modelar essa estrutura em uma tabela do PostgreSQL?

Existem três opções principais:

nomes de coluna camelCase sem aspasnomes de coluna citados camelCasenomes sem aspas (minúsculas) com sublinhados

Cada um deles tem suas desvantagens:

Os identificadores não listados dobram automaticamente para minúsculas. Isso significa que você pode criar uma tabela com umcanPlayPiano coluna, mas o caso misto nunca atinge o banco de dados. Quando você inspecionar a tabela, a coluna sempre será exibida comocanplaypiano - no psql, pgadmin, explique os resultados, mensagens de erro, tudo.

Os identificadores indicados mantêm o caso, mas depois de criá-los dessa maneira, vocêsempre tem que citá-los. IOW, se você criar uma tabela com um"canPlayPiano" coluna, umSELECT canPlayPiano ... vai falhar. Isso adiciona muito ruído desnecessário a todas as instruções SQL.

Nomes em minúsculas com sublinhados não são ambíguos, mas não mapeiam bem os nomes que o idioma do aplicativo está usando. Você terá que lembrar de usar nomes diferentes para armazenamento (can_play_piano) e para código (canPlayPiano). Isso também impede certos tipos de automação de código, em que propriedades e colunas de banco de dados precisam ser nomeadas da mesma forma.

Então eu estou preso entre uma pedra e um lugar duro (e uma pedra grande; há três opções). O que quer que eu faça, alguma parte vai parecer estranha. Nos últimos 10 anos, usei a opção 3, mas espero que haja uma solução melhor.

Sou grato por qualquer conselho que você possa ter.

PS: Eu percebo de onde vem o caso de dobra e a necessidade de cotações - o padrão SQL, ou melhor, a adaptação do padrão do PostgreSQL. Eu sei como isso funciona; Estou mais interessado em conselhos sobre práticas recomendadas do que explicações sobre como o PG lida com identificadores.