Sottoscrizioni o camelCase negli identificatori PostgreSQL, quando il linguaggio di programmazione utilizza camelCase?

Question

Questo mi ha tormenta da un po ', e non posso arrivare a una soluzione che si sente destra ...

Dato un linguaggio OO in cui è formato camelCase la solita convenzione di denominazione per le proprietà degli oggetti, e di un esempio oggetto come questo:

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

Come dovrei modellare questa struttura in una tabella PostgreSQL?

ci sono tre opzioni principali:

1. nomi delle colonne non quotate camelCase
2. nomi delle colonne camelCase citati
3. nomi non quotati (minuscolo) con sottolineature

Ognuno di essi hanno i loro inconvenienti:

1. Gli identificatori non quotati si piegano automaticamente in lettere minuscole. Ciò significa che è possibile creare una tabella con una colonna canPlayPiano, ma il maiuscolo non raggiunge mai il database. Quando controlli la tabella, la colonna apparirà sempre come canplaypiano - in psql, pgadmin, spiega risultati, messaggi di errore, tutto.

2. Gli identificatori citati mantengono il loro caso, ma una volta che li crei in questo modo, dovrai indicare sempre. IOW, se si crea una tabella con una colonna "canPlayPiano", un SELECT canPlayPiano ... avrà esito negativo. Questo aggiunge un sacco di rumore inutile a tutte le istruzioni SQL.

3. I nomi in minuscolo con caratteri di sottolineatura non sono ambigui, ma non si adattano bene ai nomi utilizzati dalla lingua dell'applicazione. Dovrai ricordarti di usare nomi diversi per la memorizzazione (can_play_piano) e per il codice (canPlayPiano). Impedisce inoltre determinati tipi di automazione del codice, in cui le proprietà e le colonne DB devono essere identificate come stesse.

Quindi sono preso tra una roccia e un luogo duro (e una grossa pietra, ci sono tre opzioni). Qualunque cosa faccia, una parte si sentirà a disagio. Negli ultimi 10 anni ho usato l'opzione 3, ma continuo a sperare che ci sarebbe una soluzione migliore.

Sono grato per ogni consiglio che potresti avere.

PS: Mi rendo conto di dove si stia piegando il caso e della necessità di virgolette - lo standard SQL, ovvero l'adattamento dello standard di PostgreSQL. So come funziona; Sono più interessato alla consulenza sulle best practice che alle spiegazioni su come PG gestisce gli identificatori.

Answer 1

Dato che PostgreSQL utilizza identificatori non sensibili alla distinzione tra maiuscole e minuscole con caratteri di sottolineatura, è necessario modificare tutti gli identificatori nell'applicazione per fare lo stesso? Chiaramente no. Quindi perché pensi che il contrario sia una scelta ragionevole?

La convenzione di PostgreSQL è nata attraverso un mix di conformità agli standard ed esperienza a lungo termine dei propri utenti. Insisti.

Se la traduzione tra nomi di colonna e identificatori diventa noiosa, chiedi al computer di farlo - sono bravi in ​​cose del genere. Immagino che quasi tutti i 9 milioni di librerie di astrazione del database possano farlo. Se hai un linguaggio dinamico ti porteranno tutte e due le righe di codice per scambiare i nomi delle colonne con gli identificatori in CamelCase.

Answer 2

Se le colonne nella PostgreSQL sono con underscores, si può mettere alias ma con doule apici.

Esempio:

SELECT my_column as "myColumn" from table;