Convenzioni ufficiali di capitalizzazione PostgreSQL [chiuso]

Esiste una convenzione PostreSQL ufficiale relativa alla capitalizzazione di nomi di DB, tabelle e campi?

Gli esempi sul sito ufficiale suggeriscono una _separazione di lettere minuscole e parole, e mi chiedo se questa politica sia ufficiale.

CREATE TABLE films (
    code        char(5) CONSTRAINT firstkey PRIMARY KEY,
    title       varchar(40) NOT NULL,
    did         integer NOT NULL,
    date_prod   date,
    kind        varchar(10),
    len         interval hour to minute
);

Fondamentalmente rispecchierò i commenti di Verace e lo affermerò, rendendolo semi-ufficiale:

Non esiste una best practice che copra ogni circostanza. Quello che segue fa i seguenti presupposti (e cosa fare se non l'hai fatto):

• Ne hai già discusso con il tuo team (le persone che lavorano da sole spesso devono solo decidersi)
• Non esiste già una definizione di stile formalizzata per SQL nel tuo team (altrimenti non te lo chiederesti)
• Non esiste una definizione di stile formalizzata per alcun codice (seguire le stesse convenzioni di base già stabilite per altre lingue e formalizzare uno stile)

Quindi il resto è piuttosto supponente ma basato sull'esperienza

1. Quando si tratta di nomi di tabelle
   1. Dovresti scegliere nomi di entità singolari (questo semplifica la documentazione)
   2. Dovresti usare Pascal Case qui
2. Quando si tratta di nomi di campi
   1. Usa camelCase sui nomi dei campi
   2. Usa nomi brevi e singolari a meno che la definizione abbia sicuramente senso come plurale (quasi mai)
3. Quando si tratta della propria funzione o dei nomi delle procedure memorizzate
   1. Usa underscore_separation
   2. Utilizzare la denominazione dei campi per la parametrizzazione
4. Quando si tratta di funzioni di database integrate o nomi di lingue (ad es. SELEZIONA)
   1. A meno che non ci sia un requisito per essere capitalizzato in un certo modo, utilizzare TUTTI MAIUSCOLI
   2. Conosci le API della tua lingua per sapere cosa è ragionevole o richiesto
5. Quando si tratta di spaziatura
   1. Molte persone usano l'allineamento delle colonne per le parole chiave e il rientro per cose che non sono parole chiave
   2. Molte persone usano le virgole all'inizio della riga quando i campi sono separati su ogni riga (Questo rende più facile commentare un campo specifico da un elenco di selezione)
   3. Non usare mai spazi come parte dei nomi delle cose, nemmeno per le intestazioni del valore di ritorno.
6. Quando si tratta di punteggiatura
   1. Parentesi - USARLI. Sono GRATUITI. Lo prometto.
   2. Punto e virgola - USARLI. Non ti distruggeranno. Ti costringono a pensare al tuo codice. E sono una buona igiene.
   3. Restituzione del carrello - Ancora una volta, sono gratuiti ;-) E rendono il tuo codice leggibile.

Dovresti anche riconoscere che mentre sto cercando di aiutarti ad applicare una guida di stile generica, che la comunità di Postgres generalmente non usa camelCase o PascalCase ma usa underscore_separation. L' importante è assicurarsi di stabilire e utilizzare uno stile specifico ovunque per essere coerenti .

Un rapido Google rivelerà molti siti che indicano le migliori pratiche. Direi solo due cose: non usare MAI gli spazi "My Table Name" (il porting diventa impossibile a causa di diversi meccanismi di escape; lo stesso vale per qualsiasi carattere non alfanumerico). Con questo tipo di meccanismi, normalmente devi anche rispettare il caso. Ci sono abbastanza lettere e parole nella lingua inglese (o la tua) e le lunghezze degli identificatori sono abbastanza lunghe (non conosco nessun sistema che abbia identifier_length <32, PostgreSQL è 64). E non usare mai parole chiave SQL (che variano in base a RDBMS) che farà la stessa cosa.

Dichiarazioni come

SELECT "Field" FROM "Table";

può essere valido! La cosa assolutamente critica è avere una convenzione chiara e relativamente semplice e poi attenersi ad essa. Le persone hanno opinioni diverse come scoprirai: leggi l'argomento e scegli ciò che "ti sembra giusto". Vedi questi siti 1 , 2 , 3 , 4 , 5 , ... (ce ne sono molti altri).