Para SQL, cuándo comenzaron a ser deseable utilizar siempre las palabras "unión interna" en lugar de unirse de forma implícita por:Para SQL, ¿cuándo comenzó a ser conveniente utilizar siempre las palabras "Inner Join" en lugar de impliedly joinly?
select * from t1, t2 where t1.ID = t2.ID;
? ¿Es solo por estilo o para distinguir entre combinación externa o hay otras razones para ello?
La sintaxis INNER y OUTER JOIN se formalizó en la especificación SQL-92. En muchos productos de bases de datos como MySQL y SQL Server, puede omitir la palabra "INTERIOR" de las combinaciones internas y simplemente usar "UNIRSE". Del mismo modo, muchos productos de bases de datos le permiten omitir la palabra "OUTER" y simplemente usar "LEFT JOIN" o "RIGHT JOIN" para uniones externas. La sintaxis anterior de combinación externa de *= o =* creó ambigüedades en muchas circunstancias. Muchos productos tienen o muy pronto dejarán de ser compatibles con la sintaxis anterior de combinación externa.
Antes de la especificación SQL-92, los proveedores usaban su propia sintaxis para indicar una combinación externa. Es decir, *= no fue universal (me parece recordar a alguien que usa ?=). Además, no implementaron la unión externa de forma universal. Tomemos el siguiente ejemplo:
Table1
Col1 Col2
1 Alice
2 Bob
Table2
Col1 Col2
1 1
2 2
3 3
4 4
Select
From Table1, Table2
Where Table2.Col1 *= Table1.Col1
La consulta anterior sería generalmente rendimiento:
1 1 1 Alice
2 2 2 Bob
3 3 Null Null
4 4 Null Null
Ahora trata de:
Select
From Table1, Table2
Where Table2.Col1 *= Table1.Col1
And Table2.Name = 'Alice'
En algunos productos de base de datos, se llega a:
1 1 1 Alice
En otros lo harías Get:
1 1 1 Alice
2 2 Null Null
3 3 Null Null
4 4 Null Null
En resumen, es ambigua en cuanto a si la filtración sobre la mesa sin conservantes se debe aplicar antes o después de la unión.
Me gusta dejar INNER y OUTER; demasiada pelusa. En todos mis años de programación con '* =' y '= *' (y hubo algunos) creo que tuve que volver a trabajar en una o dos consultas debido a las ambigüedades. Aun así, prefiero la nueva sintaxis. –
Yah. Y Oracle utiliza el omega-unirse a (+) sintaxis abominable: SELECT a, b, c desde q, r, donde qx = RY (+) debe ser SELECT a, b, c a partir de Q LEFT JOIN R en qx = ry –
Llegó a ser deseable cuando se agregó la nueva sintaxis para manejar las incoherencias con las implementaciones de unión externa.
Dado que la combinación de uniones externas e internas (y uniones externas particulares de ambas direcciones) con la sintaxis anterior es en muchos casos ambigua, se debe crear e implementar nueva sintaxis para permitir al programador tener un 100% de claridad sobre el orden y agrupación de las cláusulas de unión.
Sin embargo, sigue siendo perfectamente legal escribir las uniones internas de estilo antiguo por sí solas, pero las uniones exteriores de estilo antiguo se van en todas las formas, y es fácil deshacerse de ellas.
Se convirtió deseable cuando se hizo posible ...
El join palabra clave describe mejor la intención de que el "clásico" se unen. Además, cuando tiene muchas combinaciones en una consulta, la tabla para unirse y la condición para usar aparecen una al lado de la otra en lugar de tener todas las tablas en un lugar y todas las condiciones en otra.
Creo que es el estándar ANSI. Debería devolver un error cuando se omite la palabra clave ON, y (IMO) es un estilo más declarativo.
ANSI-92 estándar hmmm que es una pregunta difícil que voy a salir en una extremidad y adivinar 1992
Para las respuestas que dicen "para evitar ambigüedades anteriores", ¿podemos tener un ejemplo? – Oddthinking