5
Esistono regole empiriche per gli sviluppatori quando utilizzare join anziché subquery o sono gli stessi.Join query o subquery
A
risposta
2
Dipende da RDBMS. È necessario confrontare i piani di esecuzione per entrambe le query.
Nella mia esperienza con Oracle 10 e 11, i piani di esecuzione sono sempre gli stessi.
2
In teoria ogni sottoquery può essere modificata in una query di join.
3
Per quanto riguarda le prestazioni, non hanno alcuna differenza nella maggior parte dei moderni motori DB.
3
Il problema con le sottoquery è che si potrebbe finire con un sub-set di risultati senza alcuna chiave, quindi unirsi a loro sarebbe più costoso.
Se possibile, provare sempre a fare query JOIN e filtrare con la clausola ON, invece di WHERE (anche se dovrebbe essere lo stesso, poiché i motori moderni sono ottimizzati per questo).
2
Come con molte cose, dipende. - quanto complessa è la sottoquery - in una query con quale frequenza viene eseguita la sottoquery
Cerco di evitare le sottoquery ogni volta che posso. Soprattutto quando ci si aspetta che i set di risultati grandi non utilizzino mai le subquery, nel caso in cui la subquery venga eseguita per ogni elemento del set di risultati.
prendersi cura, Alex
1
In SQL Server una subquery correlata esegue di solito peggio di un join o, spesso ancora meglio per le prestazioni, un join a una tabella derivata. Non scrivo quasi mai una sottoquery per qualcosa che dovrà essere eseguita più volte. Questo perché le subquery correlate spesso trasformano la tua query in un cursore ed eseguono una riga alla volta. Nei database di solito è meglio fare le cose in un modo basato su set
2
Per ora ignoriamo l'impatto sulle prestazioni (come dovremmo fare se siamo consapevoli che "l'ottimizzazione prematura è la radice di tutti i mali").
Scegli ciò che è più chiaro e facile da mantenere.
5
Il primo principio è "Esegui la query con precisione". Il secondo principio è "dichiarare la query semplicemente e ovviamente" (che è dove di solito si fanno le scelte). Il terzo è "indicare la query in modo che possa essere elaborata in modo efficiente".
Se si tratta di un dbms con un buon processore di query, i progetti di query equivalenti dovrebbero comportare piani di query uguali (o almeno altrettanto efficienti).
La mia più grande frustrazione nell'usare MySQL per la prima volta è stata la consapevolezza che dovevo essere di anticipare l'ottimizzazione. Dopo una lunga esperienza con Oracle, SQL Server, Informix e altri prodotti dbms, raramente mi aspettavo di occuparmi di questi problemi. Ora è meglio con le nuove versioni di MySQL, ma è ancora qualcosa che alla fine devo prestare attenzione a più spesso rispetto agli altri.
È vero per le sottoquery correlate? Perché ti qualifichi con "teoricamente"? Puoi completare la tua risposta alla domanda? – dkretz