Ho avuto una query (per Postgres e Informix) con una NOT INclausola contenente una sottoquery che in alcuni casi restituiva NULLvalori, facendo sì che quella clausola (e l'intera query) non restituissero nulla.
Qual è il modo migliore per capirlo? Ho pensato NULLa qualcosa senza valore e quindi non mi aspettavo che la query fallisse, ma ovviamente non è questo il modo corretto di pensare NULL.
Risposte:
Logica booleana - o logica a tre valori
x NOT IN (1, 2, NULL) equivale a NOT (x = 1 OR x = 2 OR x = NULL)x <> 1 AND x <> 2 AND x <> NULLtrue AND true AND unknown**unknown**falsedi questo caso in quanto non passerà la WHEREcondizione **Ora, questo è il motivo per cui la gente usa EXISTS+ NOT EXISTSanziché IN+ NOT IN. Vedi anche L'uso della logica NOT in relazione agli indici per ulteriori informazioni
** Nota: unknownè uguale falsealla fine di un'espressione in una WHEREcondizione.
Mentre l'espressione viene valutata, allora non è noto
Vedi il commento di @ kgrittn qui sotto per il perché
NULL NOT IN (some_subquery), non deve restituire la riga esterna, tranne se some_subquerynon restituisce alcuna riga. Questo è il motivo per cui il piano di esecuzione quando entrambe le colonne sono in grado di null può essere considerevolmente più costoso. Esempio di SQL Server
x <> NULLche si stia risolvendoFALSE, ti aspetterestiNOT (x <> NULL)di valutarloTRUEe non lo fa. Entrambi valutanoUNKNOWN. Il trucco è che una riga viene selezionata solo se laWHEREclausola (se presente) restituisceTRUE- una riga viene omessa se la clausola restituisceFALSEoUNKNOWN. Questo comportamento (in generale e per ilNOT INpredicato in particolare) è obbligatorio per lo standard SQL.