Sintaxis de unión abreviada de Transact-SQL?

He notado algunas veces al trabajar con código henetworkingado, que puede hacer uniones 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 types de uniones, pero no he podido encontrar ninguna buena documentation completa al respecto. Entonces, ¿conoce algún buen enlace a la documentation?

Personalmente, creo que las sentencias de SQL que he visto al usar estos operadores son más difíciles de descifrar que cuando se utiliza la syntax explicada, ¿hay algún beneficio al usar la versión abreviada?

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 syntax de unión estándar. Los otros operadores que mencionas son confusos y necesitan desaparecer, me estremezco cuando los veo en los objects de la database.

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 statement 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.

Si está usando SQL Server, bajo ninguna circunstancia use esa syntax. Hay ocasiones en que se devuelven resultados incorrectos, ya que a veces SQL Server lo interpreta correctamente como una combinación externa y, a veces, interpreta esa syntax como una combinación cruzada. Como los sets de resultados de los dos son drásticamente diferentes, nunca se puede confiar en los resultados del uso de esta syntax. Además, SQL Server 2008 es la última versión de SQl Server que incluso permitirá sysntax.

Mi opinión personal (después de más de 6 años en SQL y TSQL) es que este estilo henetworkingado solo hace que sea más difícil para otros desarrolladores no versados ​​en syntax henetworkingada entender fácilmente su código. Siempre prefiero una syntax más detallada y descriptiva si el performance no se ve afectado: nunca se sabe cuándo va a tener que pasar el soporte de ese código 🙂

No utilizaría la syntax * = o = (+) ya que no son compatibles con otros RDBMS o incluso en el caso del server MSSQL compatible con versiones posteriores, a less 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 syntax * = porque era less 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 desorder 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 networkingundante 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 syntax de ANSI JOIN es más difícil de desorderar 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.