Come dedurre il risultato di una query?

Il ragionamento sul significato di una query (cioè i risultati che dovrebbe produrre) usando l'approccio procedurale ingenuo che descrivi è perfettamente corretto. Come dici tu, con query complesse spesso è l'unico modo semplice per capire cosa sta succedendo.

Il problema sarebbe se si usasse questo ragionamento per dedurre proprietà sulla query esecuzione (come la complessità temporale o l'utilizzo della memoria). Non è saggio perché il vero database utilizza probabilmente indici e tabelle temporanee e pianificatori di query contenenti tutti i tipi di ottimizzazioni della magia nera che non si devono e non si devono sapere. Finché non assumi mai ipotesi come "Le subquery annidate utilizzano molta memoria perché costruiscono tabelle temporanee" senza alcuna prova concreta, dovresti stare bene.

Se hai qualche background in matematica, potrebbe essere utile pensare a dichiarazioni dichiarative come le query SQL come definizioni di insiemi matematici. Ad esempio, il risultato di questa query:

SELECT id, name FROM table WHERE id > 10

è probabilmente equivalente a un set come questo:

S = { {id, name} | id > 10 ∧ ∃row (row ∈ table) ∧ row(0) = id ∧ row(1) = name }

Dato che la notazione del set-builder non è normalmente intesa come pseudocodice per gli algoritmi di costruzione di set, questa formazione pone una certa distanza mentale tra la definizione di query / set e l'algoritmo ingenuo che capita di implicare.

In effetti, sei in grado di determinare con precisione che cosa restituirà una query utilizzando il ragionamento logico come descritto.

Ciò che SQL non garantisce è in che modo il motore troverà questo risultato. Dà lo stesso risultato come se usasse i passi logici che descrivi, ma in che modo in realtà trova il risultato dipende da una serie di fattori e dettagli di implementazione.

Ad esempio, quando pronunci "Scegli le righe da quella tabella ..." il motore potrebbe non avere realmente bisogno di cercare una tabella, se esiste un indice che include tutte le colonne come per. Ovviamente questo significa che il motore deve prima esaminare le colonne per determinare quali tabelle o indici devono essere utilizzati. Quindi il motore non seguirà effettivamente i passaggi che descrivi, ma il risultato sarà lo stesso.

Se si assumono sottoquery correlate, il risultato sarà come se la sottoquery correlata verrà eseguita una volta per riga nella query principale, ma in realtà Query Optimizer potrebbe trasformare la query in un join che è molto più veloce da eseguire.