"<>" vs "no en"

Question

que fue depurando un procedimiento almacenado, el otro día y se encontró algo de lógica algo como esto:

SELECT something 
FROM someTable 
WHERE idcode <> (SELECT ids FROM tmpIdTable) 

Este regresó nada. Pensé que se veía un poco extraño con el "<>", así que lo cambié a "NO ENCENDIDO" y luego todo funcionó bien. Me preguntaba por qué es esto? Este es un proceso bastante antiguo y no estoy seguro de cuánto tiempo ha pasado el problema, pero recientemente cambiamos de SQL Server 2005 a SQL Server 2008 cuando se descubrió esto. ¿Cuál es la diferencia real entre "<>" y "NOT IN" y ha cambiado el comportamiento entre Server2005 y 2008?

Answer 1

SELECT something 
FROM someTable 
WHERE idcode NOT IN (SELECT ids FROM tmpIdTable) 

verifica cualquier valor en la lista.

Sin embargo, el NOT IN no es tolerantes a NULL. Si la subconsulta arrojaba un conjunto de valores que contenía NULL, no se devolverían registros en absoluto. (Esto es porque internamente el NOT IN está optimizado para idcode <> 'foo' AND idcode <> 'bar' AND idcode <> NULL etc., que siempre fallará porque cualquier comparación con NULL produce UNKNOWN, evitando que la expresión completa se vuelva VERDADERO.)

Una variante más tolerante a NULL sería esto:

SELECT something 
FROM someTable 
WHERE NOT EXISTS (SELECT ids FROM tmpIdTable WHERE ids = someTable.idcode) 

---

EDIT: I inicialmente supone que esta:

SELECT something 
FROM someTable 
WHERE idcode <> (SELECT ids FROM tmpIdTable) 

comprobaría contra sólo el primer valor. Resulta que esta suposición es incorrecta, al menos para SQL Server, donde realmente desencadena su error:

Msg 512, Level 16, State 1, Line 1 
Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression. 

Answer 2

<> es una operación "singular" NOT; NOT IN es una operación de conjunto, por lo que tiene sentido que la primera no funcione. No obstante, no tengo idea de si pudo o no haberlo hecho en una versión anterior de SQL Server.

Answer 3

probar esto, puede correr más rápido debido al uso del índice:

SELECT something 
FROM someTable 
    LEFT OUTER JOIN tmpIdTable ON idcode=ids 
WHERE ids IS NULL 

Answer 4

no tengo idea ¿Por qué escribirías algo como WHERE idcode <> (SELECT ids FROM tmpIdTable)? Una instrucción SELECT devolverá un conjunto de tuplas y su idcode ya sea o NO estará EN ESTE conjunto. "WHERE idcode NOT IN (SELECT ids FROM tmpIdTable)" es la manera de hacerlo.

Answer 5

en algunas versiones de SQL ! = se debe utilizar para una declaración lógica "no igual". ¿Has probado eso?

Answer 6

Este código es válido si y sólo si no hay filas o de una sola fila de regresar de tmpIdTable:

SELECT something 
FROM someTable 
WHERE idcode <> (SELECT ids FROM tmpIdTable) 

Si se devuelven varias filas, recibirá un error como:

Msg 512 , Nivel 16, estado 1, línea 1 La subconsulta arrojó más de 1 valor. Esto no está permitido cuando la subconsulta sigue =,! =, <, < =,>,> = o cuando la subconsulta se usa como una expresión.

Este es el mismo error que se obtiene con escalar anidada inesperadamente produce múltiples filas como:

SELECT *, (SELECT FROM t1 bla DONDE etc.) desde la T2

Nada ha cambiado WRT esto en SQL Server en una década, así que espero que las suposiciones sobre la consulta anidada en el código original se hayan roto.

Si no se devuelven las filas, el resultado estará vacío ya que <> NULL nunca es verdadero (suponga ANSI NULLs).

Este código es válido para cualquier número de filas:

SELECT something 
FROM someTable 
WHERE idcode NOT IN (SELECT ids FROM tmpIdTable) 

Sin embargo, todavía puede haber problemas con NULL.

Answer 7

Si la subconsulta SELECT devuelve cero filas, eso es NULO. Cuando se compara NULL con algo, el resultado siempre es UNKNOWN, y nunca es TRUE. De manera bastante confusa, NO DESCONOCIDO es igual a DESCONOCIDO.

Evito la lógica de tres valores (VERDADERO, FALSO, DESCONOCIDO) siempre que sea posible. No es tan difícil de evitar una vez que lo dominas.

Si la subconsulta SELECT devuelve exactamente un valor, la comparación de desigualdad debe devolver el resultado esperado.

Si la subconsulta SELECT devuelve más de un valor, debería recibir un error.

En general, NOT IN devolverá el resultado que espera cuando prueba para no ser miembro de un conjunto.

Esta respuesta se superpone a otras respuestas, pero está redactada de forma un poco diferente.

Editado para añadir más detalles acerca NO EN:

hice algunas búsquedas sobre NO EN en Oracle, y he aprendido algo que no sabía hace media hora. NOT IN es NULL sensible. En particular,

X NOT IN (SELECT ...) 

No es lo mismo que

NOT (X IN SELECT ...)) 

voy a tener que modificar mi respuesta anterior!

Answer 8

consultas utilizando NO EN pueden ser frágiles:

http://sqlblog.com/blogs/alexander_kuznetsov/archive/2008/10/21/defensive-database-programming-rewriting-queries-with-not-in.aspx