Risposta migliore
Sebbene sia i join che le sottoquery hanno il loro posto nelle istruzioni SQL, personalmente provo sempre a scrivere le mie query utilizzando esclusivamente i join . Nel frattempo, introduco una sottoquery solo quando non riesco a recuperare i dati che desidero senza uno.
Il motivo è che i join tendono ad essere eseguiti più velocemente. In effetti, mi spingerei a dire che il tempo di recupero della query utilizzando i join sarà quasi sempre più veloce di quello di una sottoquery.
Il motivo è che i join alleviano il carico di calcolo sul database sostituendo più query con una query di join. Ciò a sua volta fa un uso migliore delle capacità del database di cercare, filtrare e ordinare i record.
Ovviamente, quando si aggiungono più join a una query, il server del database deve svolgere più lavoro, il che traduce per rallentare i tempi di recupero dei dati.
Sebbene i join siano necessari per recuperare i dati da un database normalizzato, è importante che i join siano scritti correttamente, poiché i join errati possono causare un grave degrado delle prestazioni e risultati di query imprecisi.
In alcuni casi, le sottoquery possono sostituire join e unioni complessi con un effetto negativo minimo sulle prestazioni.
Esempi di sottoquery
A volte non puoi davvero andare in giro usando una sottoquery. Di seguito sono riportati un paio di esempi che utilizzano il database di esempio Sakila per MySQL e il mio Navicat sviluppo di database e client di amministrazione.
Esempio n. 1: utilizzo di una funzione aggregata come parte di una clausola JOIN
La maggior parte delle volte, le tabelle vengono unite su un campo comune. In effetti, non è insolito che il campo comune condivida anche lo stesso nome per dimostrare che si tratta degli stessi dati. Tuttavia, nella seguente query, la tabella del cliente viene unita allultimo (MAX) create\_date in modo che i risultati della query siano per il cliente che si è registrato più di recente.
Viene utilizzata una sottoquery perché non è possibile utilizzare le funzioni di aggregazione come parte di una clausola WHERE. Questa ingegnosa soluzione alternativa aggira tale limitazione!
Esempio n. 2:
In questa query, viene utilizzata una sottoquery per recuperare un set di risultati intermedio in modo da poter applicare la funzione AVG () al COUNT di film noleggiati. Questa è quella che chiamo una doppia aggregazione perché stiamo applicando unaggregazione (AVG) al risultato di unaltra (COUNT).
Questa particolare query è abbastanza veloce – impiega solo 0,044 secondi – perché la query interna restituisce un unico valore. Di solito, le query più lente sono quelle che richiedono scansioni complete della tabella.
Spero che questo risponda alla tua domanda.
Saluti!
Adam
Risposta
Di solito dovresti scrivere le query in modo che sia il più chiaro possibile e lasciare lottimizzazione al processore di query dellRDBMS e al DBA, se ne hai uno, che è responsabile della messa a punto del design fisico. dovrebbe portare a prestazioni abbastanza buone nella maggior parte dei casi, ma ci sono delle eccezioni. A volte lottimizzatore di query di un RDBMS ha punti ciechi o casi negativi.
Ora se i join o le sottoquery saranno un problema per un ottimizzatore, è molto più probabile che si trovi in sottoquery. Questo perché join è una caratteristica di base del linguaggio che tutti gli utenti, mentre molti utenti non usano affatto le sottoquery. Ho scoperto che converte unapp da Sybase a SQL Server ho dovuto riscrivere molte sottoquery come join a causa di bug in Microsoft gestione delle sottoquery – anche se in un caso molto specifico (dove la sottoquery clausola where includeva un parametro associato). Non sorprende che SQL Server contenga bug nelle sottoquery perché molti dei suoi clienti utilizzano SQL Server con gli editor grafici di query di Microsoft che producono naturalmente join ma non sottoquery.
In genere sconsiglio unottimizzazione prematura, ma farò uneccezione qui. Se la tua applicazione deve essere portabile su più piattaforme di database, nella maggior parte dei casi preferirei i join alle sottoquery perché è più probabile che tu incorra in bug o scelte errate di ottimizzatori con le sottoquery. Se il tuo lapplicazione non ha bisogno di essere portabile, scrivi la query in quello che sembra il modo più naturale e se non ci sono problemi, cosa che sarà la maggior parte delle volte, va bene. Se cè un problema, riscrivi la query in modo diverso per vedere se aiuta. E se hai un DBA, consultalo per eventuali problemi di prestazioni che hai.