operador - Sintaxis de unión abreviada de Transact-SQL?
union sql ejemplo (5)
He notado algunas veces al trabajar con código heredado, que puede hacer combinaciones externas izquierda y derecha en sql usando el
=*
como una especie de taquigrafía para "combinación externa correcta" y
*=
como una especie de taquigrafía para "combinación externa izquierda" en declaraciones como esta:
select table1.firstname, table2.lastname
from table1, table2
where table1.id *= table2.id
Supongo que hay otros operadores como estos dos para los diferentes tipos de uniones, pero no he podido encontrar ninguna buena documentación completa al respecto. Entonces, ¿conoce algún buen enlace a la documentación?
Personalmente, creo que las sentencias de SQL que he visto al usar estos operadores son más difíciles de descifrar que cuando se usa la sintaxis explicada, ¿hay algún beneficio al usar la versión abreviada?
Mi opinión personal (después de más de 6 años en SQL y TSQL) es que este estilo heredado solo hace que sea más difícil para otros desarrolladores no versados en sintaxis heredada entender fácilmente su código. Siempre prefiero una sintaxis más detallada y descriptiva si el rendimiento no se ve afectado: nunca se sabe cuándo va a tener que pasar el soporte de ese código :)
Si está usando SQL Server, bajo ninguna circunstancia use esa sintaxis. Hay momentos en los que se devuelven resultados incorrectos, ya que a veces SQL Server lo interpreta correctamente como una combinación externa y, a veces, interpreta esa sintaxis como una combinación cruzada. Como los conjuntos de resultados de los dos son drásticamente diferentes, nunca se puede confiar en los resultados del uso de esta sintaxis. Además, SQL Server 2008 es la última versión de SQl Server que incluso permitirá sysntax.
No utilizaría la sintaxis * = o = (+) ya que no son compatibles con otros RDBMS o incluso en el caso del servidor MSSQL compatible con versiones posteriores, a menos que se habiliten niveles de compatibilidad bajos. Es entonces una preocupación válida que en algún momento MS simplemente deje de apoyarlo por completo.
Me tomó un poco acostumbrarme a cambiar mis "viejos" habbits. Preferí la sintaxis * = porque era menos de escribir y se juntó con el flujo más simple de combinaciones iguales (que siguen siendo perfectamente válidas y aceptables)
Una de mis objeciones para pasar al uso de UNIONES fue todo ese tipeo y el desorden que encontré en los ejemplos de consulta al usarlos.
Algunos trucos que encontré fueron simplemente formatear problemas y saber lo que realmente se requiere. El uso de ''INNER'' y ''OUTER'' es completamente redundante e innecesario. También utilizo corchetes para delimitar el final de la cláusula de unión y poner cada condición en su propia línea:
FROM blah b LEFT JOIN blah2 b2 ON (b.ID = b2.ID)
LEFT JOIN blah3 b3 ON (b.ID = b3.ID)
...
Algunos han dicho que la sintaxis de ANSI JOIN es más difícil de desordenar porque con combinaciones iguales es fácil pasar por alto un parámetro de unión ... En la práctica, he tenido más dificultades para olvidar decir ''DONDE'' y el intérprete sigue pensando que soy definir condiciones de unión en lugar de condiciones de búsqueda que pueden conducir a todo tipo de resultados difíciles de encontrar / bizarros.
The = * y * = no están en desacuerdo con los estándares actuales de SQL, creo que estos operadores se dejarán de usar pronto. Siempre debe usar la sintaxis de unión estándar. Los otros operadores que mencionas son confusos y necesitan desaparecer, me estremezco cuando los veo en los objetos de la base de datos.
La razón por la cual tiene consecuencias involuntarias es porque interpretará la cláusula TODO WHERE como la cláusula JOIN. Ejemplo:
Seleccione1:
select * from table a left join table b on a.id=b.id
where b.name = "hello world"
VS
Select2:
select * from table a left join table b on a.id=b.id and b.name = "hello world"
Estos 2 seleccionados devuelven resultados diferentes. Cuando escribes una declaración como esta:
select * from tablea,tableb where tablea.id *= tableb.id and b.name="hello world"
Esperaría que la mayoría de la gente QUIERE los resultados de Select1 ... pero en realidad obtendrá los resultados de Select2.