Minus

[roman]

Uy. Pero entonces el minus éste se ve un poco bobo ¿no?

[jachguate]

[roman]

Je, je, yo también estoy confundido. Es que no veo clara la necesidad de un operador no estandar que puede reemplazarse tan sencillamente por algo mucho más canónico.

// Saludos

[jachguate]

Yo diría que es una característica interesante, porque permite escribir queries mas fáciles de entender. A ver si me explico:

A mi me resulta mas fácil de entender el significado de:

Código SQL [-]
select id_cliente from cliente_moroso
minus
select id_cliente from cliente_interno

suponiendo que ambas son vistas que se basan en tabla cliente, donde cliente_moroso tiene uno o varios joins a otras tablas para determinar si hay documentos pendientes de pago con cierto atrazo (de acuerdo a la configuración del sistema), mientras que cliente_interno tiene un encuentro con la tabla de empresas, donde se define el id de cliente que corresponde a cada una de ellas.

Aún cuando sea posible escribir una sentencia particular para este caso, resulta mucho mas sencillo de escribir y leer queryes, también mas flexible el uso de estos operadores (también hay un operador intersect )

Claro que cuando no contamos con ellos, tenemos que picar mas piedra, pero si podemos llegar a los mismos resultados.

Hasta luego.

[Casimiro Noteví]

Pregunto: ¿pero en esta forma de trabajar con "minus" se hacen 2 selects?
Porque si es así, entonces es mejor la forma "estandar" de firebird que es un sólo select, imagino que será más rápido y eficiente

[roman]

Entiendo lo que dices y voy de acuerdo en que resulta más legible pero como dice Casimiro, ¿no es ineficiente?

Digamos, algo como lo que ejemplificas, supongo que también puede hacerse con una subconsulta NOT IN que tengo entendido es más lenta que un JOIN. Ese minus, ¿no es como una subconsulta?

// Saludos

[jachguate]

Empezado por roman

Entiendo lo que dices y voy de acuerdo en que resulta más legible pero como dice Casimiro, ¿no es ineficiente?

Desconozco el tema de otros motores, pero en el caso de Oracle, el analizador/optimizador hace maravillas, por lo que no llegarán a ejecutarse dos consultas, una que devuelva un millón de registros y otra 999,999, para hacer la resta y devolver solo uno al final.

Oracle está en capacidad de encontrar una ruta óptima para realizar la consulta. Lo importante, como ya he resaltado, es que es mas semantico, por llamarle de alguna forma.

Empezado por roman

Digamos, algo como lo que ejemplificas, supongo que también puede hacerse con una subconsulta NOT IN que tengo entendido es más lenta que un JOIN. Ese minus, ¿no es como una subconsulta?

Muchos de los problemas que pueden resolverse con minus pueden resolverse con un not in o a veces dentro de un query sin ellos, por lo que no resulta "indispensable".

Sin embargo, si se da la opción de elegir, teniendo en cuenta que el motor sea capaz de procesarlo de manera optima, yo me quedo con los operadores sobre conjuntos.. (y muchos otros "analíticos" que tiene el oracle ese...)