Underscores ou camelCase dans les identifiants PostgreSQL, lorsque le langage de programmation utilise camelCase?

Cela me dérange depuis un moment, et je n’arrive pas à une solution qui se sent bien

Étant donné un langage OO dans lequel la convention d’appellation habituelle pour les propriétés d’object est camelCased, et un exemple d’object comme celui-ci:

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

Comment dois-je modéliser cette structure dans une table PostgreSQL?

Il y a trois options principales:

  1. noms de colonne camelCase non cotés
  2. citation des noms de colonnes camelCase
  3. Noms non cotés (minuscules) avec des traits de soulignement

Ils ont chacun leurs inconvénients:

  1. Les identifiants non cotés se plient automatiquement en minuscules. Cela signifie que vous pouvez créer une table avec une colonne canPlayPiano , mais la casse mixte n’atteint jamais la firebase database. Lorsque vous inspectez la table, la colonne apparaîtra toujours comme canplaypiano – dans psql, pgadmin, expliquez les résultats, les messages d’erreur, tout.

  2. Les identifiants cités conservent leur argumentation, mais une fois que vous les créez comme cela, vous devrez toujours les citer. IOW, si vous créez une table avec une colonne "canPlayPiano" , un SELECT canPlayPiano ... échouera. Cela ajoute beaucoup de bruit inutile à toutes les instructions SQL.

  3. Les noms minuscules avec des traits de soulignement ne sont pas ambigus, mais ils ne correspondent pas bien aux noms utilisés par la langue de l’application. Vous devrez vous rappeler d’utiliser des noms différents pour le stockage ( can_play_piano ) et pour le code ( canPlayPiano ). Il empêche également certains types d’automatisation de code, où les propriétés et les colonnes de firebase database doivent être nommées de la même façon.

Donc, je suis pris entre un rocher et un endroit dur (et une grosse pierre; il y a trois options). Quoi que je fasse, certaines parties vont être gênantes. Depuis une dizaine d’années, j’utilise l’option 3, mais j’espère que la solution sera meilleure.

Je suis reconnaissant pour tout conseil que vous pourriez avoir.

PS: je me rends compte d’où vient le pliage de cas et le besoin de citations – le standard SQL, ou plutôt l’adaptation de PostgreSQL à la norme. Je sais comment ça marche; Je suis plus intéressé par les conseils sur les meilleures pratiques que par les explications sur la manière dont PG gère les identifiants.

Étant donné que PostgreSQL utilise des identifiants insensibles à la casse avec des caractères de soulignement, devriez-vous changer tous vos identificateurs dans votre application pour faire la même chose? Clairement pas. Alors pourquoi pensez-vous que l’inverse est un choix raisonnable?

La convention dans PostgreSQL est née d’un mélange de conformité aux normes et d’expérience à long terme de ses utilisateurs. Restez avec elle

Si traduire entre des noms de colonnes et des identifiants devient fastidieux, demandez à l’ordinateur de le faire – ils sont bons dans ce genre de choses. J’imagine que presque toutes les bibliothèques d’abstraction de firebase database de 9 millions de personnes peuvent le faire. Si vous avez un langage dynamic, il vous faudra deux lignes de code pour permuter les noms de colonnes en identificateurs dans CamelCase.

Si vos colonnes dans PostgreSQL sont avec des underscores de underscores , vous pouvez mettre des alias, mais avec des guillemets doubles .

Exemple :

 SELECT my_column as "myColumn" from table;