Come posso semplificare la scrittura di query SQL complesse? [chiuso]

Sto basando la maggior parte di questo solo cercando di ottenere la risposta "giusta", quindi potresti scoprire che ci sono alcuni problemi di prestazioni. Non serve accelerare una query errata.

Comprendi le relazioni tra le tabelle : la maggior parte sarà una a molte. Conosci la tabella "molti". Identifica i campi richiesti per i tuoi join.

Pensa agli scenari di join LEFT : seleziona tutti i dipendenti e il loro stipendio dal mese scorso. E se non avessero ricevuto uno stipendio il mese scorso?

Conosci il set di risultati: 1) In un foglio di lavoro, inserisci manualmente almeno un record corretto per la tua query. 2) Scrivi la query in un formato abbastanza semplice per identificare quanti record devono essere restituiti. Utilizza entrambi per testare la tua query per assicurarti che l'adesione a una nuova tabella non altera il risultato.

Suddividi la tua query in parti gestibili - Non devi scrivere tutto in una volta. Le query complesse a volte possono essere solo una raccolta di query semplici.

Attenzione ai livelli di aggregazione misti : se devi inserire valori mensili, trimestrali e annuali nello stesso set di risultati, dovrai calcolarli separatamente nelle query raggruppate in valori diversi.

Sapere quando UNION A volte è più facile suddividere sottogruppi nelle proprie istruzioni selezionate. Se si dispone di una tabella mista a manager e altri dipendenti e in ogni colonna si devono eseguire istruzioni caso basate sull'appartenenza a uno di questi gruppi, potrebbe essere più semplice scrivere una query Manager e unione a una query Employee. Ognuno conterrebbe la propria logica. Dovendo includere elementi da tabelle diverse in file diverse è ovvio.

Formule complesse / nidificate - Prova a rientrare in modo coerente e non aver paura di utilizzare più righe. "CASO QUANDO CASO QUANDO CASO QUANDO" ti farà impazzire. Prenditi il tempo per pensarci. Salva i calcoli complessi per ultimo. Prendi prima i record corretti selezionati. Quindi attacchi formule complesse sapendo che stai lavorando con i giusti valori. La visualizzazione dei valori utilizzati nelle formule ti aiuterà a individuare le aree in cui devi tenere conto dei valori NULL e dove gestire l'errore di divisione per zero.

Prova spesso quando aggiungi nuove tabelle per assicurarti di ottenere sempre il set di risultati desiderato e sapere quale è il colpevole o il join.

1. Indentazione sarebbe la prima cosa da fare, se non lo fai già. Non solo è utile con query anche semplici, ma è fondamentale quando si tratta di join e query un po 'più complessi di un select top 1 [ColumnName] from [TableName] .

2. Una volta rientrati correttamente, nulla impedisce di aggiungere commenti all'interno della query stessa, quando appropriato. Non esagerare con loro: se il codice è abbastanza esplicito, l'aggiunta di commenti danneggerà solo la chiarezza del codice. Ma sono ancora benvenuti per le parti meno esplicite della query.

   Si noti che le query più lunghe (comprese le query con commenti) implicano un utilizzo di larghezza di banda maggiore tra il server delle applicazioni e il server del database. Tieni inoltre presente che, a meno che tu non stia lavorando a un prodotto su scala Google con un'enorme quantità di richieste al secondo, che richiede prestazioni eccezionali e utilizzo delle risorse, le dimensioni aggiunte dai commenti potrebbero non cambiare nulla in termini di prestazioni.

3. Applicare lo stesso stile su tabelle, colonne, ecc. aiuta molto anche la leggibilità. Quando un database precedente ha le tabelle PRODUCT , users , USERS_ObsoleteDONT_USE , PR_SHIPMENTS e HRhbYd_UU , qualcuno sta facendo qualcosa di molto sbagliato.

4. Anche imporre lo stesso stile sulle query è importante. Ad esempio, se stai scrivendo query per Microsoft SQL Server e hai deciso di utilizzare [TableName] anziché TableName , segui questa procedura. Se vai a una nuova riga dopo un select , non farlo nella metà delle tue query, ma tutte.

5. Non utilizzare * , a meno che non vi siano validi motivi per farlo (come in if exists(select * from [TableName] where ...) in Microsoft SQL Server). Non solo * ha un impatto negativo sulle prestazioni in alcuni (se non la maggior parte) database, ma non è nemmeno utile per lo sviluppatore che utilizza la tua query. Allo stesso modo, uno sviluppatore deve accedere ai valori per nome, mai per indice.

6. Infine, per selezionare, non c'è niente di sbagliato nel fornire una vista . Per qualsiasi altra cosa, possono essere utilizzate anche stored procedure a seconda del progetto e della gente in cui stai lavorando².

^{¹ Alcune persone odiano le stored procedure. Ad altri non piacciono per diversi motivi (perfettamente validi, almeno per loro).}

^{² I tuoi colleghi, gli altri studenti, il tuo insegnante, ecc.}

Un po 'di buio qui, ma se stai scrivendo molte viste temporanee forse non hai ancora capito che la maggior parte delle posizioni potresti inserire una tabella in un'istruzione SQL, quella tabella può essere sostituita da una query .

Quindi, anziché unire la tabella A alla vista temporanea B, puoi unire la tabella A alla query che hai utilizzato come vista temporanea B. Ad esempio:

    SELECT A.Col1, A.Col2, B.Col1,B.Col2
      FROM (SELECT RealTableZ.Col1, RealTableY.Col2, RealTableY.ID as ID
              FROM RealTableZ 
   LEFT OUTER JOIN RealTableY
                ON RealTableZ.ForeignKeyY=RealTableY.ID
             WHERE RealTableY.Col11>14
            ) As B
        INNER JOIN A
                ON A.ForeignKeyY=B.ID

Questo esempio è piuttosto inutile, ma dovrebbe spiegare la sintassi.

Per le viste che non sono "speciali" (indicizzate, partizionate), ciò dovrebbe comportare lo stesso piano di query come se si fosse utilizzata una vista.

Per semplificare la scrittura, puoi verificare ogni pezzo per assicurarti di ottenere ciò che ti aspetti prima di scrivere l'intera query.

Le mie scuse se questo è già vecchio per te.

Al posto delle visualizzazioni temporanee, utilizza la clausola WITH . Ciò rende molto più facile suddividere query di grandi dimensioni in parti più leggibili più semplici.

1. Diventa più familiare con la teoria degli insiemi se non lo sei già. SQL si basa sulla teoria degli insiemi e la comprensione di più sui set ti aiuterà a familiarizzare con il funzionamento di SQL.
2. Fai pratica con più SQl, se stai imparando solo SQL ci vorrà del tempo per capire come fare tutto, a volte ci vorrà del tempo prima che tu li capisca veramente, Joins è un grande esempio, più li usi e meglio otterrai a questo.
3. Assicurati che le tabelle che stai interrogando siano progettate correttamente
4. Non aver paura di utilizzare le visualizzazioni su query selezionate, soprattutto se hai un set comune che deve essere perfezionato in modi diversi

Come qualsiasi altra cosa, vuoi suddividere il problema in parti gestibili.

È proprio così che risolvi problemi complessi, comunque.

Quindi: vuoi controllare la sottoquery per vedere che restituisce realmente ciò che vuoi prima di eseguire una query esterna su di essa. Vuoi provare un join minimo di ogni tavolo a cui stai partecipando, in modo che tu possa vedere che stai davvero riflettendo correttamente. Cose del genere. Sperare di digitare tutto e uscire esattamente ciò che vuoi in un colpo solo non è realistico.

Un'istruzione SQL, una volta raggiunto un certo livello di complessità, è fondamentalmente un piccolo programma di per sé. Fa una grande differenza capire veramente come i dati vengono combinati, selezionati, filtrati e stampati.