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

Sto trovando molto difficile scrivere query SQL complesse che coinvolgono join su molte (almeno 3-4) tabelle e che coinvolgono diverse condizioni nidificate. Le domande che mi viene chiesto di scrivere sono facilmente descritte da alcune frasi, ma possono richiedere una quantità ingannevole di codice per il completamento. Mi trovo spesso a utilizzare viste temporanee per scrivere queste query, che sembrano un po 'una stampella. Quali suggerimenti puoi fornire per semplificare queste complesse query? Più specificamente, come posso suddividere queste query nei passaggi che devo usare per scrivere effettivamente il codice SQL?

Nota che sono l'SQL che mi viene chiesto di scrivere fa parte dei compiti a casa per un corso di database, quindi non voglio software che farà il lavoro per me. Voglio davvero capire il codice che sto scrivendo.

Maggiori dettagli tecnici:

• Il database è ospitato su un server PostgreSQL in esecuzione sul computer locale.
• Il database è molto piccolo: non ci sono più di sette tabelle e la tabella più grande ha meno di circa 50 righe.
• Le query SQL vengono inviate invariate al server, tramite LibreOffice Base.

Sto basando la maggior parte di questo sul solo tentativo di ottenere la risposta "giusta", quindi potresti scoprire che ci sono alcuni problemi di prestazioni. Inutile 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 iscritti.

Pensa agli scenari di partecipazione a SINISTRA : seleziona tutti i dipendenti e la loro busta paga dello scorso mese. E se non avessero ricevuto uno stipendio il mese scorso?

Conoscere il set di risultati: 1) In un foglio di calcolo, inserire manualmente almeno un record corretto per la query. 2) Scrivi la query in una forma abbastanza semplice per identificare quanti record devono essere restituiti. Utilizzare entrambi questi per testare la query per assicurarsi che l'unione a una nuova tabella non altera il risultato.

Suddividi la query in parti gestibili : non è necessario scriverla tutta in una volta. Le query complesse a volte possono essere solo una raccolta di query semplici.

Fai attenzione ai livelli misti di aggregazione : se devi inserire valori mensili, trimestrali e da inizio anno nello stesso set di risultati, dovrai calcolarli separatamente in query raggruppate su valori diversi.

Sapere quando in UNION A volte è più semplice suddividere i sottogruppi nelle loro dichiarazioni selezionate. Se si dispone di una tabella mista con manager e altri dipendenti e su ciascuna colonna è necessario eseguire dichiarazioni Case basate sull'appartenenza a uno di questi gruppi, potrebbe essere più semplice scrivere una query Manager e unione su una query Employee. Ognuno conterrebbe la propria logica. Dover includere elementi di tabelle diverse in righe diverse è un uso ovvio.

Formule complesse / nidificate : prova a rientrare in modo coerente e non avere paura di utilizzare più righe. "CASO QUANDO CASO QUANDO CASO QUANDO" ti farà impazzire. Prenditi il ​​tempo per pensarci bene. Salvare i calcoli complessi per ultimo. Ottieni prima i record corretti selezionati. Quindi attacchi formule complesse sapendo che stai lavorando con i giusti valori. Vedere i valori utilizzati nelle formule ti aiuterà a individuare le aree in cui devi tenere conto dei valori NULL e dove gestire la divisione per zero errori.

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

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

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

   Si noti che query più lunghe (incluse query con commenti) significherebbero un maggiore utilizzo della larghezza di banda tra il server delle applicazioni e il server del database. Inoltre, a meno che non si lavori su un prodotto su scala Google con un'enorme quantità di richieste al secondo, che richiedono prestazioni e utilizzo delle risorse eccezionali, le dimensioni aggiunte dai commenti potrebbero non cambiare nulla in termini di prestazioni.

3. Applicare lo stesso stile su tabelle, colonne, ecc. Aiuta anche la leggibilità. Quando un database legacy ha i tavoli PRODUCT, users, USERS_ObsoleteDONT_USE, PR_SHIPMENTSe HRhbYd_UU, qualcuno sta facendo qualcosa di molto sbagliato.

4. È importante applicare lo stesso stile anche alle query . Ad esempio, se si stanno scrivendo query per Microsoft SQL Server e si è deciso di utilizzare [TableName]invece di TableNameattenersi. Se si passa a una nuova riga dopo una select, non farlo solo nella metà delle query, ma in tutte.

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

6. Infine, per alcuni, non c'è nulla di sbagliato nel fornire una vista . Per qualsiasi altra cosa, le procedure memorizzate possono anche essere utilizzate a seconda del progetto e delle persone¹ con cui stai lavorando².

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

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

Un po 'uno scatto al buio qui, ma se stai scrivendo molte viste temporanee forse non ti sei ancora reso conto che la maggior parte dei posti potresti mettere una tabella in un'istruzione SQL, quella tabella può essere sostituita da una query.

Pertanto, anziché unire la tabella A alla vista temporanea B, è possibile unire la tabella A alla query utilizzata 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 utilizzasse una vista.

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

Mi scuso se questo è già un vecchio cappello per te.

Invece di visualizzazioni temporanee, utilizzare la clausola WITH . Ciò rende molto più semplice suddividere le query di grandi dimensioni in parti più piccole più leggibili.

1. Acquisisci maggiore familiarità con la teoria degli insiemi se non lo sei già. SQL si basa sulla teoria degli insiemi e la comprensione più approfondita degli insiemi ti aiuterà a familiarizzare con il funzionamento di SQL.
2. Pratica più SQl, se stai solo imparando SQL ci vorrà del tempo per capire come fare tutto, qualcosa richiede solo tempo prima di capirli davvero, I join sono un ottimo esempio più li usi e meglio ci riuscirai.
3. Assicurarsi che le tabelle di cui si sta eseguendo la query siano progettate correttamente
4. Non aver paura di usare le viste su query selezionate, specialmente se hai un set comune che deve essere perfezionato in diversi modi

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

Questo è davvero il modo in cui risolvi problemi complessi, comunque.

Quindi: vuoi controllare la sottoquery per vedere che restituisce davvero quello che vuoi prima di eseguire una query esterna su di essa. Vuoi provare un join minimo di ogni tabella a cui ti stai unendo in modo da poter vedere che ci stai davvero pensando correttamente. Cose del genere. Sperare di digitare tutto ed uscire esattamente quello che vuoi in una botta è semplicemente irrealistico.

Un'istruzione SQL, una volta raggiunta una certa complessità, è fondamentalmente un piccolo programma in sé e per sé. Fa una grande differenza capire davvero come i dati vengono combinati, selezionati, filtrati e prodotti.