oop - practices - ¿Indica o camelCase en los identificadores PostgreSQL, cuando el lenguaje de programación usa camelCase?

naming conventions database design

Question

Esto me ha estado molestando por un tiempo, y no puedo llegar a una solución que se sienta bien ...

Dado un idioma OO en el que la convención de nomenclatura habitual para propiedades de objeto es camelCased, y un objeto de ejemplo como este:

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

¿Cómo debo modelar esta estructura en una tabla de PostgreSQL?

Hay tres opciones principales:

1. nombres de columna camelCase sin cita
2. nombres de columnas camelCase citados
3. nombres sin comillas (minúsculas) con guiones bajos

Cada uno tiene sus inconvenientes:

1. Los identificadores sin comillas se doblan automáticamente a minúsculas. Esto significa que puede crear una tabla con una columna canPlayPiano , pero el caso mixto nunca llega a la base de datos. Cuando inspeccione la tabla, la columna siempre aparecerá como puede canplaypiano - en psql, pgadmin, explicar resultados, mensajes de error, todo.

2. Los identificadores entre comillas mantienen su caso, pero una vez que los crea así, siempre tendrá que citarlos. IOW, si creas una tabla con una columna "canPlayPiano" , SELECT canPlayPiano ... un SELECT canPlayPiano ... Esto agrega mucho ruido innecesario a todas las sentencias de SQL.

3. Los nombres en minúsculas con guiones bajos no son ambiguos, pero no se corresponden bien con los nombres que usa el lenguaje de la aplicación. Deberá recordar usar diferentes nombres para el almacenamiento ( can_play_piano ) y para el código ( canPlayPiano ). También previene ciertos tipos de automatización de código, donde las propiedades y columnas de DB necesitan ser nombradas de la misma manera.

Así que estoy atrapado entre una roca y un lugar duro (y una piedra grande, hay tres opciones). Cualquier cosa que haga, alguna parte se sentirá incómoda. Durante los últimos 10 años más o menos, he estado usando la opción 3, pero sigo esperando que haya una mejor solución.

Estoy agradecido por cualquier consejo que pueda tener.

PD: Me doy cuenta de dónde viene el plegado de casos y la necesidad de presupuestos: el estándar SQL, o más bien la adaptación del estándar de PostgreSQL. Sé cómo funciona; Me interesan más los consejos sobre las mejores prácticas que las explicaciones sobre cómo PG maneja los identificadores.

Answer 1

Dado que PostgreSQL usa identificadores que no distinguen entre mayúsculas y minúsculas, ¿debería cambiar todos sus identificadores en su aplicación para hacer lo mismo? Claramente no. Entonces, ¿por qué crees que lo contrario es una elección razonable?

La convención en PostgreSQL ha surgido a través de una combinación de cumplimiento de estándares y experiencia a largo plazo de sus usuarios. Quedarse con eso.

Si la traducción entre los nombres de las columnas y los identificadores se vuelve tediosa, que la computadora lo haga; son buenos para cosas como esas. Supongo que casi todas las 9 millones de bibliotecas de abstracción de bases de datos pueden hacerlo. Si tiene un lenguaje dinámico, le tomará las dos líneas de código para intercambiar nombres de columna a identificadores en CamelCase.

Answer 2

Si sus columnas en PostgreSQL tienen underscores , puede poner alias pero con comillas dobles .

Ejemplo:

SELECT my_column as "myColumn" from table;