Corretta formattazione della sintassi per SQL? [duplicare]

Mi piace usare le parole chiave SQL

SELECT, FROM, WHERE , ecc in MAIUSCOLO

Per quanto riguarda i nomi delle tabelle e dei nomi delle colonne, li scrivo così come esistono nella tabella / colonna

No, non c'è consenso sulla formattazione SQL.

Le cose più comuni su cui le persone sono d'accordo è di distinguere tra colonne / tabelle e funzionalità. IE: SELECT, GROUP BY, HAVING ... sono in maiuscolo, mentre i riferimenti delle colonne sono in minuscolo per rendere più evidente ciò che è.

Mi piace la riga delimitare le mie clausole: spesso mi vedrai scrivere di nuovo query su SO come:

SELECT t.group_name 
  FROM GROUP_TABLE t
 WHERE t.group_code = 'GRP37X'

Alcuni mettono la virgola all'inizio del riferimento di una colonna piuttosto che alla fine - rende più facile commentare le colonne specifiche:

SELECT t.group_name 
     , t.column
  FROM GROUP_TABLE t
 WHERE t.group_code = 'GRP37X'

vs

SELECT t.group_name, 
       t.column
  FROM GROUP_TABLE t
 WHERE t.group_code = 'GRP37X'

Se hai bisogno di capire una query, ad esempio, per correggere un bug, devi essere in grado di guardarlo e rispondere rapidamente ad alcune domande:

• quante colonne nel set di risultati?
• quali sono i loro nomi?
• quali tabelle sono coinvolte nella query?
• quali sono i criteri di partecipazione?

Quindi, per migliorare la comprensione della velocità di comprensione, mi piace rendere il mio SQL più tabulare possibile, specialmente WRT alla clausola from e ai criteri join . Nell'elenco di selezione, mi piace usare la sintassi column-name = expression perché rende le cose molto più leggibili. Ometto anche le parole chiave opzionali nella grammatica SQL. Non ha senso dire left outer join' when left join will do: there is no such thing as a left inner join '.

Questo non è molto importante per le query banali: se la tua query è qualcosa sulla linea di

select * from foo where foo_date between @lowBound and @hiBound

non importa molto. Ma più grandi e complesse diventano le query, più importante diventa tutto. Se la query è lunga 400 righe e comprende 18 tabelle con subquery annidate, criteri di join molto complicati e altre bruttezze diverse, l'SQL ben formattato è molto importante per la capacità di comprendere il codice. Questo è vero anche se sei l'autore del codice in questione. Quando si tratta della possibilità di creare codice "scrivi una volta", Perl non ha nulla su SQL.

Molti anni di lavoro di manutenzione su codice esistente e sciatto mi hanno portato a un modulo simile a questo:

select column_name         = <some-expression>    ,
       another_column_name = <another-expression> ,
       ...
from      dbo.some_table        t1
left join dbo.another_table     t2 on t2.some_table_id = t1.id
join      dbo.yet_another_table t3 on t3.id            = t2.another_table_id
                                  and exists ( select ...
                                               from ...
                                               where <correlation-criteria>
                                               and <filtering-criteria
                                             )
join ( select ...
       from ...
       where ...
     ) t4 on t4.id = t3.widget_id
where t1.xxx = t4.yyy
  and t2.zzz = ( select count(*)
                 from ...
                 where ...
               )

Gerald Weinberg ha sottolineato all'inizio degli anni '70 nel suo lavoro seminale, La psicologia della programmazione informatica , che la lingua più importante da conoscere per un programmatore di computer è l'inglese, non [insert-the-programming-language-of-choice-here]: la scrittura e la manutenzione di programmi per computer è un compito sociale (qualcosa uno fa con le persone: il computer è semplicemente uno strumento). Per quanto riguarda il vero codice sorgente, il compilatore non si preoccupa di come appare, purché analizzi correttamente. Tuttavia, le persone che hanno bisogno di lavorare con quel codice sorgente si preoccupano: devono essere in grado di eliminarlo.

Alla mente umana piace l'ordine: gli spazi bianchi e l'allineamento delle colonne tabulari sono i tuoi amici.

In genere, le parole riservate sono tutte maiuscole mentre i riferimenti di tabella e colonna corrispondono a qualsiasi cosa si trovi nel database. Ad esempio, se salvi le tabelle in caso Pascal, le inserirai nel tuo T-SQL in caso Pascal.

In genere dico perché dipende dalle regole aziendali per tali cose. Come dici tu, le persone lo fanno in tutti i modi diversi. SQL non ha una preferenza, quindi spetta ai poteri essere quello di specificare come deve essere gestita la custodia.

Ho trovato un buon collegamento a un sito che fornisce ciò che ritengono dovrebbero essere le regole aziendali per tutto ciò che è presente nel server SQL, non solo l'intelaiatura della sintassi: link

Non sarei d'accordo con il loro involucro, ma rispetto profondamente il fatto che abbiano uno standard che rispettano. Questo è più importante di quello che è lo standard.

Non conosco un consenso, ma io personalmente uso # 3 e per la maggior parte vedo 1 e 3 il più (escluso il codice di Microsoft).

Non mi piacciono le maiuscole perché rendono la lettura più noiosa (anche se solo inconsciamente.

Come dice Biggs, il caso degli oggetti segue in genere gli standard di denominazione della persona. Uso tutti i nomi di variabili e colonne più bassi con nomi di tabelle a caratteri misti e caratteri di sottolineatura tra le parole. Trovo che sia il più facile da leggere rapidamente, e leggere e capire il codice è più importante per me della quantità minima di tempo trascorso effettivamente digitandolo. Ad ogni modo, poiché è così che chiamo gli oggetti, ecco come appaiono nel mio codice.

Naturalmente, dato che sono un consulente, quando vado in un nuovo cliente, seguo qualunque standard di denominazione che hanno in atto, condividendo le mie opinioni su di esso se lo chiedono.

Raccomando di attenersi alle convenzioni di denominazione Oracle o utilizzare PascalCaseing per tabella / procedura / nomi di indici / trigger e under_score per campi e variabili.