Code SQL di formattazione delle query

Per motivi di controllo del codice sorgente, abbiamo interruzioni di riga dopo ogni clausola where o virgola. Quindi il tuo sopra si trasforma in

SELECT bla 
     , bla2 
     , bla 
FROM   bla 
WHERE  bla=333 
  AND  bla=2
ORDER  BY nfdfsd
        , asdlfk;

(la tabulazione e l'allineamento non hanno uno standard qui, ma le virgole di solito sono in testa)

Ancora, non fa alcuna differenza di prestazioni.

Una query di 1600 colonne sembra avere bisogno di una revisione seria da parte di un buon DBA.

Se una query è complessa, la avvolgo. Se è semplice, lo lascerò come una riga singola a meno che non sia troppo lungo, quindi inizierò a ricomporlo di nuovo.

Tutto riguarda la gestibilità e la comprensione di ciò che si suppone che faccia in modo che il wrapping o il non wrapping possano essere decisi al volo, a meno che la tua organizzazione non abbia alcune regole di formattazione del codice.

Ri: si tratta di una cattiva pratica di codifica. Quasi! È una buona pratica. Non ci sono buone ragioni per cui so di usare una query così lunga e molte buone ragioni per riformattarla. Come ho detto prima, un abile DBA probabilmente ha bisogno di lavorarci sopra.

L'unico vantaggio delle query a linea singola che viene in mente è che queste query potrebbero essere un po 'più facili da usare per grep. A parte questo, però, sono perplesso. Personalmente, preferisco le query più leggibili e suddivise.

I commenti multilinea sono buoni, quasi di vitale importanza quando si gestiscono grandi volumi di SQL. E se il tuo linguaggio di programmazione ha citazioni di heredoc, è ancora meglio (dato che molti editor possono evidenziare la sintassi SQL in essi).

Esempio:

$a = SQL<<<
    SELECT a, b, c, d
    FROM Foo f
    WHERE f.a = ?
SQL;

Quando lavori con query di dozzine di righe (o centinaia) sia il rientro che gli spazi bianchi rendono il testo lavorabile.

Sembra che si tratti in particolare della definizione di una grossa query all'interno di un linguaggio di programmazione, vedendoti mettere la query all'interno di una stringa letterale e concatenarla.

Se è un linguaggio compilato, non dovrebbe fare alcuna differenza - una delle prime ottimizzazioni che il compilatore farebbe è di concatenare automaticamente i valori letterali delle stringhe insieme, così si finisce comunque con una stringa grande.

Per quanto riguarda la sintassi, dovresti considerare di spostare la query al di fuori del tuo codice - memorizzarla in un file di risorse .sql separato e far leggere al tuo software quel file. Utilizzare le istruzioni preparate per le variabili, se non è una query creata dinamicamente (ad esempio, clausole where aggiunte in base a determinati parametri). Se è compilato dinamicamente, puoi aggiungere variabili sostitutive, inserendo parametri aggiuntivi dove e quando necessario.

Come per le 1600 colonne, consiglio seriamente di costruire una vista per questo, quindi invece di

SELECT column1, column2, .... column1600 from X where Y

riceverai

SELECT * FROM viewX WHERE y

Molto più conciso nel tuo codice.

Spesso utilizzo il formato proposto da @glasnt per risolvere una query complicata, tuttavia di solito ho query in una singola riga.

Questo potrebbe non rispondere alla tua domanda, ma suggerirei anche di suddividere la tua query in query più piccole. Ovviamente ciò dipende dalla query, ma più clausole e join vengono aggiunti alla query, meno il motore SQL è in grado di ottimizzare la query.

Il tuo fornitore di database dovrebbe avere strumenti come EXPLAIN di MySQL (o l'impostazione SHOWPLAN_ALL di MSSQL) che ti mostrerà cosa sta facendo il database dietro le quinte per ottimizzare la tua query, ogni volta che il database deve creare una tabella temporanea o qualcosa del genere, tu stiamo aggiungendo enormi ritardi quando parli di più utenti simultanei.

Spostando ciò che potrebbe sembrare logica insignificante dall'SQL e nel tuo codice, puoi fornire notevoli aumenti delle prestazioni - SQL è ottimo per operazioni semplici.

L'ovvio beneficio a questo riguardo potrebbe riguardare te, è che le tue query sono molto meno complesse e facili da leggere: facili da gestire (non per le colonne di > 1600) e più veloci. Sicuramente una vittoria a tutto tondo.

Spero che questo aiuti:)