Combinaciones SQL explícitas vs implícitas

Personalmente prefiero la sintaxis join ya que hace más claro que las tablas se unen y cómo se unen. Pruebe a comparar consultas SQL más grandes en las que selecciona entre 8 tablas diferentes y tiene mucho filtrado en el dónde. Al usar la sintaxis de unión, separa las partes en las que se unen las tablas de la parte en la que está filtrando las filas.

En MySQL 5.1.51, ambas consultas tienen planes de ejecución idénticos:

mysql> explain select * from table1 a inner join table2 b on a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.02 sec)

mysql> explain select * from table1 a, table2 b where a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.00 sec)

table1 tiene 166208 filas; table2 tiene alrededor de 1000 filas.

Este es un caso muy simple; de ninguna manera prueba que el optimizador de consultas no se confundiría y generaría diferentes planes en un caso más complicado.

La segunda sintaxis tiene la posibilidad no deseada de una combinación cruzada: puede agregar tablas a la parte FROM sin la correspondiente cláusula WHERE. Esto se considera perjudicial.

La primera respuesta que dio utiliza lo que se conoce como sintaxis de unión ANSI, la otra es válida y funcionará en cualquier base de datos relacional.

Estoy de acuerdo con grom en que debe usar la sintaxis de unión ANSI. Como han dicho, la razón principal es la claridad. En lugar de tener una cláusula where con muchos predicados, algunos de los cuales unen tablas y otros restringiendo las filas devueltas con la sintaxis de unión ANSI, está aclarando a ciegas qué condiciones se están utilizando para unir sus tablas y cuáles se están utilizando para restringir los resultados.

@lomaxx: Solo para aclarar, estoy bastante seguro de que ambas sintaxis anteriores son compatibles con SQL Serv 2005. Sin embargo, la sintaxis siguiente NO es compatible

select a.*, b.*  
from table a, table b  
where a.id *= b.id;

Específicamente, la unión externa (*=) no está soportada.

En cuanto al rendimiento, son exactamente los mismos (al menos en SQL Server), pero tenga en cuenta que están desaprobando esta sintaxis de unión y no es compatible con sql server2005 desde el principio.

Creo que está pensando en los operadores obsoletos *= y =* vs. "outer join".

Acabo de probar los dos formatos dados, y funcionan correctamente en una base de datos SQL Server 2008. En mi caso se produjeron planes de ejecución idénticos, pero no podía decir con confianza que este siempre sería verdad.

En algunas bases de datos (notablemente Oracle) el orden de las uniones puede hacer una gran diferencia en el rendimiento de las consultas (si hay más de dos tablas). En una aplicación, tuvimos literalmente dos órdenes de diferencia de magnitud en algunos casos. El uso de la sintaxis de unión interna le da control sobre esto, si utiliza la sintaxis de sugerencias correcta.

No especificó qué base de datos está utilizando, pero la probabilidad sugiere SQL Server o MySQL donde no hace ninguna diferencia real.

Como ha declarado Leigh Caldwell, el optimizador de consultas puede producir diferentes planes de consulta basados en lo que funcionalmente se parece a la misma instrucción SQL. Para leer más sobre esto, echa un vistazo a las siguientes dos publicaciones de blog: -

Una publicación del equipo de Oracle Optimizer

Otra publicación del blog de "Datos estructurados"

Espero que encuentres esto interesante.

En cuanto al rendimiento, no debería hacer ninguna diferencia. La sintaxis de combinación explícita me parece más limpia, ya que define claramente las relaciones entre las tablas en la cláusula from y no desordena la cláusula where.

En mi experiencia, el uso de la sintaxis cross-join-with-a-where-clause a menudo produce un plan de ejecución con daño cerebral, especialmente si está utilizando un producto de Microsoft SQL. La forma en que SQL Server intenta estimar los recuentos de filas de tablas, por ejemplo, es salvajemente horrible. El uso de la sintaxis de unión interna le da cierto control sobre cómo se ejecuta la consulta. Así que desde un punto de vista práctico, dada la naturaleza atávica de la actual tecnología de bases de datos, tienes que ir con la unión interna.