Cita: Y ahora tambien se que no todos los RDBMS necesitan de esa estructura para nombrar ALIAS, en el caso de MySQL no es necesario poner AS.
De todas formas el estandar SQL, desde sus inicios, señala que debe mantener la palabra clave AS o en su defecto incluir el ALIAS entre comillas dobles. Para que otras RDBMS, como es el caso de ORACLE, no den errores con tal sentencia...
En realidad, la obligatoriedad del AS se eliminó del estandar ANSI-SQL hace ya bastantes años. Tanto MySQL como otros DBMS conservan su uso sólo por compatibilidad de versiones antiguas, pero no es obligatorio ni siquiera en el estandar.
En otros DBMs, como Oracle, puede ser que versiones anteriores a la 8 puedan exigirlo, pero puedo asegurarte que a partir de Oracle 8 ya no es mandatorio, ya que yo mismo trabajo en base de datos para una empresa con ése, y ninguna consulta de ningún stored procedure, de ningún packaging los incluye... y no por ello fallan.
Los que si puede suceder también es que algún conector en especial requiera el uso del AS por cuestiones de forma soportada (el ODBC, por ejemplo, no soporta ciertas sintaxis que MySQL usa).
Volviendo a tu problema, tu duda no se entiende demasiado. Me explico:
Ese tipo de operaciones se resuelve usando INNER JOIN, tal y como te lo puse de ejemplo más arriba, ya que INNER JOIN devuelve todos los registros donde el valor en los campos del ON sea el mismo. Eso lo puedes ver usando dos tablas con mucha facilidad.
El único detalle y diferencia entre usar dos o usar más tablas es que debes razonar la secuencia de lectura y las relaciones:
- La primera tabla es la primera en ser leída, por tanto debe ser la que siempre devuelva la mayor parte de los registros donde haya mayores variaciones. En el caso de Personas, la lista de personas. En el caso de Facturas, la lista de encabezados de facturas, y así sucesivamente.
- El primer INNER JOIN devuelve una tabla resultado de las que se denomina
tabla derivada, porque
deriva de un JOIN. Es ese resultado como tabla virtual lo que el DBMS usa para hacer el segundo JOIN, no las tablas anteriores.
- El segundo JOIN se hace sobre la tabla resultado como un todo, aún cunado el alias del campo en el ON indique a una sola de ellas. Eso no quiere decir que esté haciendo el JOIN con la tabla pura anterior, porque esa ya no existe a nivel lógico, lo que se indica es que busque el campo que correspondía a esa tabla y que está en la derivada. Lo que existe es la tabla derivada.
- Todo JOIN posterior sigue la misma lógica: Se apoya sobre la tabla resultado de A INNER JOIN B INNER JOIN C como un todo, y sucesivamente los siguientes hacen lo mismo.
¿Se entiende la lógica de esto?
Hay algunos detalles a tener en cuenta:
- Si una relación del ON es
opcional, es decir, puede que no todos los de la tabla inicial tengan relación con ello, no se debe usar INNER JOIN sino LEFT JOIN. Pero debes tener en cuenta que si tienes un JOIN posterior, éste no devolverá datos que correspondan a la tabla derivada donde esos datos sean NULL.
- Debes encadenar la secuencia de tablas de un modo correcto. Como el JOIN ya teniendo una dependencia secuencial, si uno de los JOIN intermedios devuelve menos de los que necesita uno posterior, los datos que podría devolver el siguiente pueden ser menos de los reales. Por eso digo siempre que en los JOIN, el orden de los factores si altera el producto.
Espero que esto se entienda
