This page was exported from Recursos para programadores [ https://eldesvandejose.com ]
Export date: Mon Aug 19 10:52:08 2019 / +0000 GMT

Uniendo tablas MySQL (I). Introducción.



Iniciamos aquí una pequeña serie de artículos dedicados a las consultas MySQL que afectan a dos o más tablas. Cuando, en una consulta, necesitamos recurrir a dos tablas, significa que ambas están relacionadas entre sí, en una relación de 1-m o de m-1. Cuando se recurre a consultas que implican más de dos tablas, puede tratarse de que alguna de ellas esté relacionada con las demás en relaciones del tipo mencionado, o bien que dos tablas estén relacionadas entre sí, en una relación de tipo m-n, a través de una tercera tabla intermedia.

Además, podemos encontrarnos con la necesidad de construir consultas que impliquen relaciones "especiales", bajo determinadas circunstancias, como veremos en esta serie. Procuraremos analizar las sintaxis adecuadas en los casos que se nos presenten, de modo que, cuando tengas necesidad de consultas de este tipo, puedas hacerlas del modo más óptimo posible.

En estos artículos presentaremos la sintaxis MySQL. Esto significa que podría haber algunas diferencias si tu motor de base de datos SQL es otro (SQL Server, SQLite, etc). Optar por MySQL ha sido una decisión lógica, teniendo en cuenta que es el motor de bases de datos relacionales más empleado en Internet, con mucha diferencia y, desde luego, por méritos propios.

EL ESCENARIO

En este artículo vamos a empezar trabajando con consultas entre tablas que implican una relación m-1. Tendremos dos tablas. En una de ellas almacenamos usuarios y en la otra vamos a almacenar las provincias en las que residen dichos usuarios. Así pues, tenemos una relación en la que un usuario reside en una provincia, y en una provincia puede haber uno o más usuarios. Además, se puede dar el caso de que ciertos usuarios no tengan asignada ninguna provincia de residencia porque, en el momento de registrarlos, no sabíamos cuál es dicha provincia. Además, para poder filtrar los usuarios por un criterio (a fin de poder construir consultas más completas), les hemos asignado una categoría, llamada premium, que cada usuario puede o no tener activada. La estructura de nuestra base de datos, a la que llamamos consultas_1.sql, es la siguiente:

Como ves, son dos tablas muy sencillas que, en un escenario real se quedarían "cortas" de datos para cualquier aplicación mínima, pero con el valor didáctico necesario para este artículo.

RELACIONANDO LAS TABLAS DIRECTAMENTE

En este apartado vamos a ver como relacionar ambas tablas directamente, usando el campo id_provincia de la tabla usuarios y el campo id de la tabla provincias. El objetivo es obtener, mediante una consulta, aquellos usuarios que son premium, junto con el nombre de la provincia en la que residen. Así pues, los usuarios que no son premium no saldrán en los resultados. Tampoco obtendremos en los resultados aquellos usuarios que, aún siendo premium, no tienen asignada una provincia. La consulta es la siguiente:

SELECT login, provincia 

FROM usuarios, provincias

WHERE premium = 'S' AND provincias.id = id_provincia;

Conceptualmente, esta es la manera más simple de efectuar esta consulta.

CONSULTAS INNER JOIN

El mismo resultado que en el apartado anterior lo podemos obtener mediante una consulta con INNER JOIN (literalmente, "unión interna"). Al principio, cuesta un poco más familiarizarse con esta técnica, porque la sintaxis adecuada no es tan intuitiva como la anterior. Sin embargo, hay dos razones básicas para preferir la que vamos a ver aquí:

La consulta que nos interesa, en este ejemplo, y para obtener el mismo resultado que antes, es la siguiente:

SELECT login, provincia 

FROM usuarios

INNER JOIN provincias

ON provincias.id = id_provincia

WHERE premium = 'S';";

Vamos a ver lo que hacemos:

Como buena práctica, para cuando se incluyen campos de dos o más tablas en una consulta SQL, es adecuado desambigüar los campos siempre, incluso aunque, en este momento no parezca necesario. Esto se debe a que, a lo largo de la vida de una aplicación, las estructuras de las tablas pueden variar y, donde hoy no hay conflictos con los nombres de los campos, mañana pueden surgir, obligándonos a modificar el código. La consulta que hemos visto en este apartado debería, por lo tanto, quedar así:

SELECT usuarios.login, provincias.provincia 

FROM usuarios

INNER JOIN provincias

ON provincias.id = usuarios.id_provincia

WHERE usuarios.premium = 'S';";

EN CONCLUSIÓN

En este artículo hemos sentado las bases de las uniones (JOIN), mostrando un ejemplo que ilustra al objetivo y la forma de uso de las más simples: las INNER JOIN o uniones internas. La base de datos y un script que ejecuta estas consultas pueden obtenerse en este enlace. En el próximo artículo iremos un paso más allá, con las uniones externas.

ATENCIÓN. En el script que ilustra estos artículos accedemos a la base de datos por PDO. Si no estás familiarizado con este modo de trabajo, te recomiendo leer, antes de seguir adelante, este artículo y, este otro.

 

 


Post date: 2017-04-29 16:02:57
Post date GMT: 2017-04-29 16:02:57
Post modified date: 2019-03-25 19:39:25
Post modified date GMT: 2019-03-25 19:39:25

Powered by [ Universal Post Manager ] plugin. MS Word saving format developed by gVectors Team www.gVectors.com