Hoy vamos a hacer un curso de SQL desde cero.
Vamos a explicar qué es SQL, para qué sirve, cómo funciona y un montón de cosas.
Vamos a hacer ejercicios prácticos, ¿vale?
Para cada vez que aprendamos una cosa, pues un ejercicio práctico y así todo el día.
Vamos a hablar del lenguaje SQL.
SQL, ya os podéis imaginar, no es un lenguaje de programación o...
Pero es un lenguaje de consultas estructuradas.
Eso es lo que significa SQL, Structure Query Language.
Y como se llama esto, es un lenguaje específico de dominio que quiere decir que está específicamente diseñado para poder administrar, consultar sistemas de gestión de bases de datos.
Ahora bien, una cosa importantísima.
SQL es un estándar.
Muy poca gente lo entiende, pero es que SQL, aunque es de 1970, que es bastante antiguo, después de un tiempo se hizo un estándar en 1987.
A partir de ahí tiene una especificación.
¿Y qué pasa? Que pese a que es un estándar, como lo es JavaScript, pese a eso, vais a ver que los motores como MySQL, PostgreSQL y tal, no son 100% SQL Complain muchas veces.
Postgre es más Complain que MySQL.
Son pequeños cambios que puede ser que te tengas que adaptar, ver la documentación y tal.
No es nada grave, pero verás que hay veces que dirás, ostras, pues esto justo no me funciona.
Bueno, cada uno tiene ligeras variaciones, pero todos se basan en el mismo, en este estándar, ¿vale?
Pero antes de ponernos con SQL, tenéis que entender que es una base de datos relacional, porque tenemos base de datos relacionales, que son las llamadas toda la familia SQL,
y las que no son relacionales, que son las no SQL.
Cuando hablamos de una base de datos, tenemos que pensar como en una cosa muy grande.
Vamos a tener la primera, y aquí en la primera vamos a tener, por ejemplo, el motor de base de datos, ¿no?
Por ejemplo, aquí podríamos tener MySQL, Postgre o SQLite, ¿no? Cualquiera de estos.
O sea, nosotros tenemos un motor de base de datos.
Dentro del motor de base de datos, lo que vamos a tener en cada uno de estos, lo que vamos a tener son bases de datos.
Cuando hablamos de una base de datos, podemos tener más de una base de datos dentro de nuestra colección.
O sea, que aquí podríamos tener, por ejemplo, Twitter.
Imaginad que Twitter, pues resulta que tiene otra cosa ahí interna, que son las nóminas de los empleados.
No hace falta que tenga una base de datos, ¿no?
Twitter tendrá un montón, y a lo mejor una es solo para la aplicación de Twitter.
Dentro de esta base de datos, tendríamos lo que le llamaríamos tablas.
Cada base de datos tiene diferentes tablas.
Entonces, esta podría ser una tabla que aquí, imaginad que es la tabla de los tweets.
Tweets, y aquí tendríamos el message, y tendríamos otra tabla por aquí, que podrían ser los users.
Cada usuario, pues tendrá aquí su username.
Pero bueno, los tweets, obviamente, también están escritos por un usuario.
¿Por qué se le llaman base de datos relacional?
Porque tú cuando tienes aquí user1, user1, user5, user3, user8.
Y aquí tenemos, vamos a poner uno, tres, cinco, ocho.
Y aquí el username, esto es el onmask.
Y aquí también tenemos a van der Haag, ¿vale?
Ponemos aquí lorem, ipsum.
Aquí vamos a poner uno, dos, tres.
Y aquí tenemos bla, bla, bla.
Y la velada del ano.
Pero hablamos de bases de datos relacionales, porque lo que intentamos en este tipo de bases de datos es optimizar y evitar la duplicidad de los datos.
De forma que creamos relaciones entre las tablas para evitar la duplicidad de los mismos datos.
Que fíjate que aquí, en lugar de poner aquí el username y repetir que esto aquí, en lugar de poner userid, poner el onmask.
¿Qué pasa?
¿Qué pasa si resulta que el onmask se cambia de nombre?
Pues que si tú pusieras aquí, en lugar del userid, hubiéramos puesto aquí el username, este uno, en lugar del id.
Utilizamos el onmask.
Fijaos que hubiéramos tenido que cambiar constantemente en todas las tablas donde están las referencias del onmask e ir tendiendo que cambiar.
Que esto es una cosa que ocurriría en NoSQL.
Se llama relación porque estamos creando relaciones para evitar la duplicidad de los datos.
Así que utilizamos la id para referenciar y crear una relación entre la tabla tweets y la tabla usersid.
Así que si queremos recuperar de este tweet, el tweet del principio, este que tenemos aquí, queremos recuperar qué usuario ha sido, lo que único que tenemos que decir, vale, voy a recuperar esta id aquí, vamos a ir acá.
Recuperamos aquí y ya podemos sacar el nombre del usuario, que es el onmask.
Esto sería como funciona y esta es la clave diferencia que tiene base de datos relacional con base de datos no relacional.
La base de datos relacional tendríamos tablas, podríamos entender que son entidades, vale, y que las entidades tienen atributos.
La entidad sería en este caso tweets y aquí tendríamos, por ejemplo, los atributos que tienen la id, tienen los mensajes y el userid.
Y además creamos relaciones con otras tablas.
¿Por qué no SQL esto es totalmente diferente para bien y para mal?
Muchas veces, mucha gente lo explica de una forma técnica, que te dice, ¿cuál es la diferencia técnica?
Vale, la diferencia técnica es que la base de datos relacional crea estas relaciones y en no SQL, en lugar de tener tablas, lo que tenemos son colecciones de documentos.
Y ahí sí, lo que hacemos es duplicar los datos.
No nos importa la diferencia clave entre SQL y no SQL.
Luego veremos y podríamos pensar, oye, que en MongoDB, por ejemplo, te permite crear relaciones.
Hay un montón de formas de crear relaciones.
Pero hablando a nivel de core, ¿vale?
De la esencia misma.
SQL relaciona los datos y esto lo que hace es evitar duplicidad.
¿Cuál es lo negativo de esto?
Negativo.
Al evitar la duplicidad, esto significa que para recuperar tú los datos de un tuit, si quieres ir a Twitter, por ejemplo, imagina Twitter.
Este tuit lo quiero mostrar.
¿Qué pasa?
Tengo que recuperar la información del tuit, el avatar del usuario, el nombre del usuario, cuándo lo escribió, cuántos likes tiene...
Es mucha información.
Por lo tanto, cuando tú quieras recuperar la información del tuit, vas a tener que hacer muchas consultas para recuperar toda la información que te interesa.
Lo positivo es la coherencia que van a tener siempre los datos.
Porque si el usuario se cambia el nombre, como lo tienes en una tabla, solo lo cambias en una tabla y ya lo tienes.
Pero sobre todo quiero que os entendáis por qué a veces utilizarías uno y a veces utilizarías otro, ¿no?
Entonces, no SQL.
Aquí tendríamos, estos son tablas y aquí lo que tendríamos serían colecciones de documentos.
Puedes relacionar los documentos, pero es más costoso porque no está construido para esto.
O sea, la construcción de hacer relaciones es mucho peor.
Aquí evitas la redundancia de datos que, por lo tanto, haces que sean más pequeñas las bases de datos porque no tienes que estar repitiendo constantemente los datos, ¿vale?
Así que lo vamos a tener aquí.
Ocupan menos porque no estás repitiendo datos.
Pero claro, ¿qué pasa en NoSQL?
Que esto se hace a posta.
Lo que hacemos en SQL, por ejemplo, para un tuit, tú tendrías aquí directamente toda la información del tuit.
Intentarías poner todo lo que puedas y más en el mismo sitio, en el mismo documento.
¿Por qué harías esto si esto luego va a tener un problema, no?
Y luego tendrías el usuario también.
Y aquí tendríamos, esto sería el tuit con el texto hola mundo, ¿no?
Esto sería el tuit.
Pero también tendrías en otro sitio el user ID con la misma información.
¿Por qué te interesaría hacer esto?
Porque tú aquí lo que estás favoreciendo es hacer consultas más rápidas.
Tú lo que estás favoreciendo es decir, no, es que yo lo que quiero es consultar rápidamente la información.
Por lo tanto, negativo, que luego a la hora de normalizar los datos es problemático.
Esto seguro que os ha pasado en YouTube, en Twitter, en un montón de sitios.
Porque este tipo de redes sociales tan grandes suelen utilizar NoSQL.
¿Por qué?
Porque tienen que hacer muchísimas consultas.
Y no es tan importante que los datos realmente estén mostrando siempre la información correcta.
Os habrá pasado con los likes de YouTube, con los likes de Twitter, con comentarios que a lo mejor salen un poco más tarde.
O que según donde entras a ver ese post sale con información diferente, porque en un sitio no han editado, en otro no.
Lo que está pasando ahí es que como las consultas se hacen mucho más rápida, el problema es que los updates se tienen que hacer en todos los documentos.
Imagínate que tú te cambias el username de MiduDev.
Claro, tendrías que cambiarlo aquí, ¿no?
Y tendría que poner aquí Midu.
Pero es que me tendría que ir a todos los tweets y cambiar también Midu.
Y esto va a ser un proceso más lento que puede ocurrir que tú veas datos que no están correctos, ¿no?
O sea, lo que vas a tener aquí es justamente ver que no siempre los datos están con la última versión.
O sea, que no tienes la integridad de los datos.
No está garantizada.
¿Pero qué pasa?
Lo positivo es que va a ser muchísimo más rápido para hacer consultas.
Especialmente consultas grandes.
Ahora, ¿qué es normalizar?
Normalizar es que si tú aquí cambias en este documento, pones Midu, normalizar es que este cambio tiene que llegar a todos los sitios.
Porque si no, la integridad de los datos estaría mal.
El ejemplo más típico muchas veces que podéis ver es este, ¿vale?
Tienes una base de datos, por ejemplo, librería.
Y es que en Excel se ven claramente las tablas.
Fijaos, tendríamos los atributos a nivel de columna.
Y tendríamos cada uno de los elementos a nivel de fila.
Y aquí tenéis un ejemplo sencillísimo.
Tenemos una base de datos llamada Library, donde tenemos una tabla de libros y una tabla de Orders.
Y lo que queremos, pues claro, si en el Orders, para no tener que poner, por ejemplo, el título del libro, puedes utilizar la IDE.
Y ahí tenemos una relación sencilla.
Si queréis poneros a jugar un poquito con todo lo que vais a aprender hoy, yo os recomiendo mucho que utilicéis MySQL o SQLite.
Suelen ser los que están bastante bien para empezar, son bastante rápidos, se hacen fácil, funcionan en todos los sistemas, Windows.
MySQL, una cosa que tiene es, en Windows y en MacOS se instalan igual.
Y os voy a decir cómo lo hago yo en MacOS.
Aquí en Downloads vais a tener diferentes, ¿vale?
MySQL, no sé qué, no sé cuánto.
El que os tenéis que instalar, porque fijaos que pone Enterprise Edition, Cluster, esto se puso seria la cosa.
Porque lo compró Oracle y hay que cobrar, hay que cobrar.
Pero bueno, no os preocupéis porque tenéis aquí MySQL Community GPL Download.
Veis aquí que tenéis MySQL Installer for Windows.
Si tenéis Windows, este está súper bien.
Lo instaláis y directamente aquí ya os va a preguntar todo lo que necesitáis.
Súper fácil, se ha ido los pasos, ponéis una versión y os instaláis.
El Engine, una versión del Engine, si puede ser la última estable, mejor.
El Workbench, porque os va a ayudar bastante.
Y el Shell, esas son las tres cosas que tenéis que poner.
No necesitáis más.
Cuando os diga lo de Downloads, por cierto, veis que aquí os pone uno de 2.4 y otro de 428.
Instalaros el de 428.
Fijaos aquí que os pide iniciar sesión.
No inicie sesión.
Le dais aquí, no, thanks.
Just start my download.
Esto para la gente de Windows, súper fácil.
En la gente de Macos, lo que yo os recomiendo que hagáis es instalaros solo y específicamente MySQL Workbench.
¿Vale?
Vais aquí, Macos y aquí vais a tener la versión.
Le decís a todos.
Yo tengo Silicon, o sea que tenéis ARM y ya está.
¿Y qué hacéis con lo demás?
Bueno, con lo demás, si tenéis Macos, yo te voy a recomendar...
A ver, no voy a decir que es el mejor, pero para mí una herramienta que es básica, básica para trabajar con bases de datos.
Que se llama DB Engine, que está súper chulo.
Os lo podéis descargar y con esto podéis iniciar servicios MySQL, PostgreSQL, Redis y bueno, irán poniendo más, ¿vale?
Esta herramienta está súper chula, os la voy a enseñar, DB Engine.
Y lo que podéis hacer, una vez que la tengáis, es que además de que os detecta todos los...
¿Ves? Es esta.
Además de que os detecta toda la base de datos que tenéis.
¿Ves? Ahí me está detectando un Redis, aquí me está detectando un MySQL.
Le podéis dar aquí y podéis iniciar un MySQL, un Redis, Postgre.
Le podéis decir la versión y directamente se descarga tanto los binarios como se descarga lo que necesites.
Le puedes pasar directamente la configuración, le puedes poner el nombre que quieras.
Pero para practicar todo el tema de sintaxis, vamos directamente, porque me parece brutal, me parece buenísimo, este recurso.
Este recurso es genial para aprender SQL y luego además tiene ejercicios interactivos que está brutal,
que es el que vamos a hacer y el que nos va a ayudar un montón. Así que vamos a darle cañita.
Lo primero que necesitamos cuando tenemos una tabla es poder pedir la información.
Lo bueno que tiene SQL es que es tan fácil de entender.
Una vez que ves la información, o sea, una vez que ves la sintaxis, dices, va, la entiendo.
Pero luego vas a ir viendo que se complica un poco, que tienes que tener claro cómo funcionan las cláusulas y todo esto.
Entonces vas a ver que esto empieza fácil, pero que se va a ir complicando, ¿vale?
Lo primero que vamos a querer siempre que tengamos una tabla es extraer la información.
Aquí tendríamos una tabla, por ejemplo, con la idea, el título, el director, el año y la longitud de las películas.
Y aquí podemos ver que la idea es autoincremental.
Esto lo vais a ver que es muy típico en tablas SQL en general de hacer unas ideas que son autoincrementales.
Y a veces son bastante útiles porque si, por ejemplo, quieres hacer un counter de cuántos elementos hay,
puedes recuperar el último elemento y ver cuál es la idea y ya lo tendrías, en lugar de tener que contar los elementos.
Una idea, por ejemplo, yo que sé, que sea un identificador único.
Por ejemplo, para un usuario, normalmente no vas a querer utilizar este tipo de ideas porque ya estarías como que es muy fácil saber cuál va a ser la siguiente idea.
Siempre vas a querer generarla.
Pero para cosas que no sean críticas, a veces puede ser interesante utilizar autoincremental y luego veremos cómo las podemos crear, ¿vale?
En este caso tenemos el primer ejercicio ya que nos dice, encuentra el título para cada película.
Podemos ver cómo es una sentencia de SQL.
Primero pondríamos la acción que queremos hacer, aquí queremos decir seleccionar, luego le diríamos aquí la columna a la que queremos atacar.
En este caso, cuando ponemos asterisco, es que son todas.
La ejecución de esta consulta es lo que vemos aquí.
Ya nos está trayendo todas las columnas de la tabla Movies.
E importante, en SQL sí que necesitáis el punto y coma al final, ¿vale?
Porque si no, si no ponéis el punto y coma, la vais a hallar pardísima.
Entonces, ya teníamos aquí el select, tenemos el asterisco y nos dice que encontremos el título.
Pues evidentemente podemos utilizar el title.
Ya está, ponemos el title y ya hemos recuperado el title.
Una cosa importante que tenéis que saber sobre SQL es que SQL no es case sensitive.
O sea, podemos poner todo esto en minúscula.
Por ejemplo, select from movies.
Y esto sigue funcionando.
O lo podríamos poner todo en mayúscula, ¿vale?
Tanto, ya ves, hasta aquí, la tabla, o podríamos hacer en minúscula esto y lo otro en mayúscula y esto seguiría funcionando.
Pero, pero, la recomendación es que las palabras claves las pongas en mayúscula.
Lo que son nombres de columnas, tablas y todo esto, lo pongas en minúscula.
Tenete en cuenta una cosa.
Esto es hablando de SQL.
Pero, ¿qué pasa?
Que hay algunos motores de bases de datos que tienen cambios en concreto, como por ejemplo, PostgreSQL, que sí es case sensitive.
Pero yo os hablo de SQL, como del estándar, la especificación más clásica.
Pero si veis diferencias de documentación de PostgreSQL, por ejemplo, que entendáis que cada uno, pues puede cambiar.
Para que no os vuele luego la cabeza, que ya os veo.
Entonces, ahora nos dice el director.
Vale, este es fácil.
Select director.
Vale, ahora nos dice título y director.
Si queremos recuperar dos columnas a la vez, tenemos que poner title, director.
Así que ya sabemos cómo podemos recuperar dos columnas a la vez.
Una cosa muy interesante que tenemos cuando hacemos sentencias SQL, todos los resultados cuando utilizamos SQL son tablas.
O sea, son tablas virtuales, no físicas.
Pero toda la información que nos representa siempre son con tablas.
Da igual lo que hagas, como si quieres eliminar una tabla.
Tú eliminas una tabla y lo que vas a ver es que la información, cómo te devuelve la información, es con una tabla.
Así que es muy importante que lo entiendas.
Nunca te va a devolver un número suelto, un true.
Cosas así.
Siempre que estés utilizando comandos con select, update, create table y todo esto, vas a ver que siempre te está contestando con tablas.
Bueno, entonces ya tendríamos el title and year.
Vale, seguimos con el siguiente.
Aquí tenemos cada uno de los ejercicios de las tareas.
Vale, year, fácil.
Vale, y ahora toda la información.
Lo único que tenéis que hacer es utilizar asterisco.
Una cosa muy interesante sobre asterisco.
Esto es universal.
El asterisco lo que hace es recuperar todas las columnas de la tabla.
Obviamente tienes que tener en cuenta dos cosas.
Una, que te devuelve todos los datos y por lo tanto es mucho más costoso.
Siempre y una de las primeras optimizaciones que vas a querer hacer cuando hagas consultas en bases de datos
es recuperar solo la información que te interesa.
Porque cuanta menos información tenga que recuperar, más rápido va a ir.
Un asterisco es como el smell más grande del mundo.
¿Ok?
Porque lo que estamos haciendo aquí es decir, tráemelo todo.
Y esto obviamente muchas veces tiene problemas de rendimiento.
Así que para temas de debug sí que lo puedes hacer.
¿Vale?
Puedes decir, vale, voy a mirar todo lo que tiene.
Pero para utilizarlo en producción siempre vas a querer evitarlo.
Incluso, ¿vale?
Porque alguien dirá, oye, ¿y si quiero todas las columnas?
Incluso, incluso si quieres todas las columnas, también puede ser buena idea que especifiques qué columnas quieres.
Porque tú el día de mañana puede ser que añadas más columnas.
Y piensa que en todos aquellos sitios que has dejado un asterisco se va a traer todas las columnas.
Así que tenlo en cuenta.
Las siguientes son queries pero ya con constraints.
¿Qué quiere decir constraints?
Bueno, obviamente vamos a querer hacer consultas pero filtrando nuestros resultados.
Vamos a querer tener cláusulas para filtrar.
Y para eso vamos a utilizar el operador where.
Donde vamos a ponerle una condición.
Donde vamos a decirle, oye, recupera esto y esto y esto de la tabla donde ocurra cierta condición.
Y además podemos tener más de una condición.
O sea, como un if.
Podemos decirle que pase esto y esto o esto.
¿Ok?
Ahora, dentro del where podemos utilizar un montón de operadores.
Por ejemplo, podéis utilizar operadores numéricos para que sea igual, diferente, menor, mayor o igual que.
También está muy chulo porque tiene unos que son como más léxicos.
O sea, no son solo numéricos.
Que tenéis el between, ¿no?
Tenéis el between que le podéis decir un rango de dos números.
Por ejemplo, si la temperatura está entre 20 y 25, ¿no?
Between 20 and 25.
Eso sería una condición.
O lo puedes negar siempre con el not delante.
Lo mismo con el in para ver si algo existe en una lista de números.
Si esta columna está, no sé, si esta película es del año del 92, del 94 o del 96, ¿no?
Pues si está aquí, lo vamos a poner.
Y también al revés.
Esto está muy bien porque obviamente siempre vais a querer filtrar los datos.
No os olvidéis nunca de los where.
Entonces, vamos con el ejercicio.
Ahora que ya hemos entendido el where, lo primero que vamos a querer hacer.
Encuentra la película que tiene la idea con 6.
¿Vale?
Este es el más típico y este es súper importante y súper interesante.
¿Por qué?
Porque esto es el más básico que vais a querer hacer normalmente.
Cuando queréis recuperar un usuario, queréis recuperar lo que sea.
En este caso, queremos uno en concreto.
Le decimos where ID sea igual a 6.
Y ya hemos recuperado que es Incredibles.
Y aquí tenemos toda la información.
Tenemos el asterisco.
Por eso nos salen todas las columnas.
Ahora, ojo, nos dicen que el año esté entre el 2000 y el 2010.
Vale, pues le cambiamos el where.
Y le decimos donde el year esté entre 2000, ¿vale?
And 2010.
Y ya lo tenemos.
Y ahora nos han puesto ya todas las películas.
Que dice que no esté entre el 2000 y el 2010.
Súper fácil.
Porque ya tenemos aquí, ya hemos visto que con el not lo podemos negar.
Y la misma condición la pondríamos.
El where por ahora parece fácil.
Pero bueno, ya veréis que esto se complica.
Encuentra las 5 primeras películas de Pixar y su año de lanzamiento.
O sea, las primeras 5 películas.
Como en este caso, esto también es bastante tricky, ¿no?
Porque aquí, ¿cómo puedes saber si son las 5 primeras?
Esto es lo que os comentaba de los IDs autoincrementales.
Que muchas veces también os puede ayudar para determinar cuándo se han creado.
En este caso, como nos están diciendo las 5 primeras,
ya me puedo imaginar que como las IDs parece que son autoincrementales
y parece que los años van encrechendo conforme se van poniendo nuevas películas.
Aquí lo que vamos a querer es que donde la ID esté between 1 y 5, ¿no?
Vamos a tener las 5 primeras películas.
Las que estén entre el 1 y el 5.
Porque vamos a tener la 1, la 2, la 3, la 4 y la 5.
Si no hubiéramos puesto esto, ponemos la 6,
ya estaría metiendo una película más que no la que queremos.
Esto lo podemos hacer así.
Luego lo podríamos hacer con otras cosas.
Lo haremos con el order by más adelante
para que veas también cómo hacerlo con otras cosas.
Pero aquí lo que estamos haciendo es
aprovecharnos de la ID, que es autoincremental,
para hacer justamente esto.
Otra cosa, claro, yo entiendo que...
Claro, dice Pixar.
Pero claro, no podemos saber si son de Pixar.
No sé si todas son de Pixar.
A lo mejor sí, ¿no?
Sí, todas son de Pixar.
O sea que ya podemos entender que podemos hacer esto.
Si no, también podríamos poner between 1 y 5.
Y también a lo mejor deberíamos mirar
si la película es de Pixar y la ID, no sé qué,
y ordenarla y limitarla.
O sea, se puede hacer un montón de formas.
Aquí lo deberíamos hacer así.
Y como nos dice que tenemos que quedarnos con el año,
lo mejor que siempre deberíamos hacer, el año.
¿Vale?
Vamos a por el siguiente,
que el siguiente es todavía más interesante,
porque empieza a hacerse más complicada la cosa,
porque la cláusula WHERE que hemos visto está bien,
pero puede ir más allá.
Ya hemos visto el operador para hacer comparaciones con ID,
con números,
pero también ahora vamos a ver todo lo que es con cadenas de texto.
Por ejemplo, podemos utilizar el igual con una cadena de texto
para asegurarnos que es exactamente igual a la cadena de texto.
O podemos decir que sea diferente,
tanto así, que es muy parecido a JavaScript,
o con esto.
A mí nunca me ha gustado este,
lo tengo que decir.
A veces lo he visto y como que,
ay, me cuesta.
Pero este operador también es válido.
Luego teníamos el like.
El like es como una comparación exacta de la cadena de texto,
pero case insensitive.
O sea, va a mirar que sea exactamente esa cadena de texto,
pero sin importarle si son mayúsculas o minúsculas.
Tened en cuenta que las dos anteriores,
estas dos que tenéis aquí,
sí que tienen en cuenta,
sí que son case sensitive.
Tened en cuenta que, por supuesto,
el like y el no es like,
también las comparaciones que hacéis
van a tener un coste en cuanto al rendimiento
de la base de datos.
O sea, no es lo mismo hacer una comparación
con el igual con un case sensitive,
que seguramente va a ir más rápido,
que hacerlo con el case insensitive,
porque va a tener que revisar muchísimo más.
Luego tenemos también aquí el porcentaje.
Lo que hace es,
para utilizarlo en cualquier sitio de una cadena de texto,
y ver si machea una secuencia de caracteres.
Por ejemplo,
si ponemos call name,
like,
y este trozo,
lo que va a mirar es
add,
addic,
add,
con dos T's,
cat,
por ejemplo,
¿ves?
Aquí lo tenemos que terminar.
O sea,
vamos a ver si la cadena de texto,
si esta columna tiene una cadena de texto,
¿qué incluye la cadena de texto add?
Entonces,
no solo al principio,
sino que también puede ser en medio,
al final,
en cualquier sitio.
Sí,
efectivamente,
como una regex.
Es un control F,
me ha gustado esa,
control F,
buena esa.
Luego tendríamos este,
que es el underscore,
que lo que hace es buscar,
que solo machee con un carácter,
¿no?
Que tenga,
dice,
only with like,
call name,
like,
and,
para que machea el and,
pero no el and,
sin nada.
O sea,
tendríamos,
es como decirle,
ahí va un carácter,
¿vale?
Es como ponerle un interrogante,
¿qué va ahí?
Bueno,
pues no lo sabemos.
Y luego tendríamos lo mismo que el in y el not in,
que hemos visto con el números,
lo mismo con las cadenas de texto.
Vamos a hacer el ejercicio,
que está bastante interesante.
Dice,
porque mira,
ya dice,
encuentra todas las películas de Toy Story.
A ver,
aquí podríamos hacer la del like,
¿no?
O sea,
podríamos decir,
encuentra todas las películas de movies,
y le decimos where,
el title,
like,
y aquí utilizamos con cadena de texto,
¿vale?
Utilizando las dobles comillas,
o comillas,
creo que con comillas siempre da muy funciona,
aunque yo siempre utilizo doble comilla aquí.
Pondríamos Toy Story,
terminamos aquí las comillas,
y ya lo tendríamos,
¿vale?
Aquí estamos buscando
todos los títulos
que incluye Toy Story.
Aquí lo tendríamos,
¿vale?
O sea,
que también lo podríamos poner así,
y aquí también nos lo devolvería.
¿Por qué?
Porque todas empiezan por Toy Story,
y aquí no importaría lo que tiene después.
Pero bueno,
entiendo que por el ejercicio
podéis ir por aquí los tiros.
Pero si no,
lo podríais poner aquí,
y aquí lo que tendríamos es
todo lo que empieza
con Toy Story.
Luego,
encuentra todas las películas
que han sido dirigidas por John Lasseter.
A ver,
este es bastante fácil,
y de hecho,
este me sorprende que lo pongan,
porque este sería
que el director
sea exactamente igual,
a John Lasseter.
Lo que podéis hacer aquí,
para este,
por si queréis probar,
una cosa que puede ser interesante,
es lo del like.
O sea,
si aquí podréis,
director,
like,
y aquí ponéis
John Lasseter,
y si os fijáis,
lo ponéis todo en minúscula,
esto va a seguir funcionando,
porque aquí podemos ver
que el like,
lo que hace,
es que hace la búsqueda
case insensitive,
o sea,
no le importa.
Tú puedes ponerlo todo en minúscula,
yo estoy poniendo todo en minúscula,
y los está encontrando igualmente.
Fijaos que si lo cambias por un igual,
entonces no lo encuentra.
Pero de nuevo,
es más costoso,
¿vale?
O sea,
esta operación es más costosa que la otra,
porque obviamente,
esta cuesta más.
¿Por qué no pones el porcentaje aquí?
En este caso,
no necesitamos el porcentaje,
¿vale?
El porcentaje se utilizaría
como para buscar
que incluye ese texto,
pero no te importa dónde.
Imagínate que utilizamos el porcentaje,
el porcentaje es súper peligroso.
Si ponemos aquí porcentaje
y ponemos A,
¿vale?
Esto lo que hace es encontrar
todos los directores
que contienen la A.
Si ponemos RA,
estos son,
bueno,
claro,
esto,
a ver,
a ver si la A,
no.
Pero lo que estamos buscando aquí
es buscar
lo que incluye,
los directores que incluyen
el texto K.
Lo que queremos es exactamente
y pensar que eso es más costoso,
¿vale?
O sea,
tened en cuenta la cosa,
cuanto más global
en la búsqueda,
¿sabes?
Cuanto más posibilidades
es más lenta.
Entonces,
cuanto más específicos
es más rápido.
¿Qué es lo más específico?
ID igual a 3.
Eso es súper específico.
Están buscando específicamente
que tenga la ID 3.
Lo correcto aquí sería
utilizar justo
la forma de su nombre
con mayúsculas.
Pero hay veces
que no lo sabemos
o que el usuario
incluye información
en una búsqueda.
Por ejemplo,
imagínate que en un input,
aquí por ejemplo,
¿no?
Tenemos aquí,
aquí en esta búsqueda,
en este buscar
que tenemos aquí,
imagínate que pone
JavaScript.
Bueno,
mira,
un error.
Claro,
pero fíjate
que aquí este JavaScript
es con mayúsculas
y yo lo he puesto aquí
con minúsculas.
A veces,
tiene sentido
hacer el like
porque no sabes
lo que va a guardar
en lo que va a ponerte
el usuario.
En este caso,
sí que tiene sentido
por lo mejor el usuario
lo ha puesto así
y lo vas a querer utilizar
con el like.
Pero si puedes hacerlo
específico,
intenta hacerlo específico.
Pero a veces
no podemos controlarlo,
¿vale?
Dice,
encuentra todas las películas
y director
no dirigidas
por John Lasseter.
Bueno,
este era fácil,
¿no?
Porque lo que tenemos que hacer
es que el director
obviamente sea diferente
a John Lasseter,
¿vale?
Estos serían todos
y luego las de Wall-E
que también lo hemos visto,
serían todas las películas
que el título,
le ponemos like
y aquí le ponemos
Wall-E
aquí
y ya lo tendríamos,
¿vale?
Así que ya hemos visto
también con cadenas de texto
constraints,
bastante interesante.
Filtraje y orden
de los resultados
de las búsquedas
o de las consultas.
Vamos por partes.
Uno,
tenemos la palabra clave
distinct,
lo que va a hacer
es hacer una distinción.
¿Qué quiere decir?
Que si por ejemplo
le decimos,
venga,
devuélveme todas las películas
que han sido del año 1995
y entonces nos devuelve
todas las películas
y resulta que decimos,
bueno,
pues ahora quiero que evites
que me salgan
todas las películas
que tengan el mismo nombre
porque se ve
que hay películas
que se llaman igual
y pues con el distinct
podríamos evitar
que nos aparezcan
esos elementos
que están repetidos.
O sea,
estamos haciendo
como los valores únicos
de esa columna.
Lo mismo podríamos decir
como,
encuéntrame todos los niños
que empiezan por la letra M
y entonces habría 80 migueles.
Vale,
pues podrías hacer un distinct
para que el miguel
solo lo aparezca una vez.
Eso lo vamos a ver ahora
con un ejercicio
bastante interesante,
bastante importante
y también muy interesante
a la hora de hacer
algunas optimizaciones
de rendimiento.
Luego tenemos
lo de ordenar resultados,
ordenar por resultados
es muy sencillo.
Es decirle,
¿por qué columna
quiero ordenar los resultados
y si lo quiero ascendente
o descendente?
Ascendente,
ya os podéis imaginar
que en el caso
de un número
pues va a ser
1, 2, 3,
o sea,
de menor a mayor,
descendente,
de mayor a menor.
También tened en cuenta
que por supuesto
funciona con cadenas
de texto
y dependiendo
de la base de datos,
hay algunas
que sí que tienen
en cuenta acentos,
también depende
en la misma base de datos
con qué codificación
la has hecho,
si la has hecho
con VTF-8,
con ISO 3,
1, 6, 2, 3,
no sé qué,
o sea que depende mucho,
pero normalmente
tened en cuenta
que la A
va antes que la B,
pero la A
con mayúscula,
dependiendo
de la codificación,
veréis
que puede cambiar
el orden,
solo para que lo sepáis,
¿vale?
Por si os vuela la cabeza.
Y luego obviamente
limitar el número
de resultados
e incluso saltar.
Podéis limitar
el número de resultados,
imagináis que tenéis
mil millones
de resultados
y dice,
bueno,
solo me interesa
limitarlo,
solo quiero uno
o me quiero saltar
los cinco primeros
y luego lo quiero limitar.
Esto también está
bastante chulo
y está bien
porque el limit
funciona después
de que lo hayan ordenado,
o sea,
podéis limitarlo
después del orden,
o sea,
no sería al revés,
sino sería bastante
problemático.
Y también limitar
es importantísimo
porque obviamente
es la clave
de la optimización,
limitar el número
de resultados.
Hay un montón
de páginas
como por ejemplo
aquí tenéis
Reddit,
Pinterest
y todo esto,
que esto
es como funciona.
Tú cuando entras
a Pinterest,
bueno,
y para cualquiera,
¿no?
Para paginar.
A ver,
explorar,
JavaScript,
a ver si ahora sí,
a lo mejor es con la búsqueda.
Vale,
¿ves?
Pues aquí
se ha recuperado,
yo qué sé,
3, 4, 5,
los 15 primeros,
limítame
y 15 primeros.
Vale,
offset 0,
¿por qué?
Porque quiero los 15 primeros,
pero cuando bajo,
¿vale?
Bueno,
ya veis que no para
de ir cargando.
¿Qué es lo que está haciendo?
Está diciendo,
vale,
limita,
me devuelves 15
y en cada paginación
haces un offset
de las 15
que ya habíamos recuperado
anteriormente.
Y así es como hace la paginación,
así es como funciona exactamente
la paginación
de casi todas las páginas web.
Limitan el número de resultados,
15,
offset,
primera página,
0.
¿Por qué?
Porque no me quiero saltar ninguno,
pero en la siguiente página
limitamos a 15 resultados otra vez,
pero quiero que te saltes
los 15 de antes,
así que offset 15.
En la siguiente página,
limit 15,
pero el offset será de 30,
porque ya hemos hecho
las 30 anteriores,
¿no?
Y así constantemente.
Vamos con los ejercicios.
Mira,
dice,
lista todos los directores
de las películas de Pixar
sin duplicados,
¿vale?
Aquí vais a ver la gracia
de utilizar el Disting
y vamos a ver la diferencia
entre el Disting y el No.
Dice,
todos los directores de Pixar
alfabéticamente sin duplicados.
Primero,
vamos a querer recuperar
solo los directores,
así es,
Select Director,
aquí los tenemos.
No están ordenados alfabéticamente,
así que le decimos que
Order By Director,
¿vale?
Ahora sí que los tenemos
ordenados alfabéticamente,
pero claro,
piensa que salen repetidos,
es normal,
porque si miramos el title,
cada director en esta tabla,
claro,
Andrew Stanton ha sacado
Finding Nemo,
Andrew Stanton también hizo Wall-E,
entonces es normal
que aunque tú visualmente
haciendo así digas,
ostras,
¿por qué sale dos veces?
Es normal,
porque esa fila
en realidad
esconde más información
que tú no ves
y es que lo que está pasando
es que en realidad
hay más información
y es que este director de aquí
en realidad es por el título
de Finding Nemo,
Buscando a Nemo.
Por eso sale duplicado,
¿vale?
No es que se duplique
de la nada,
sino que realmente
tiene sentido.
Si nosotros
queremos realmente decir,
ostras,
quiero que el director
sea sin duplicados,
le tenemos que decir
Disting,
queremos distinguir
las columnas
con valores únicos,
¿vale?
Y por eso
queremos el director único,
no queremos que se repitan.
Claro,
el tema es que ahora
si ponemos aquí title,
pues vais a ver
que vuelve a ocurrir
el mismo problema,
porque no podemos
hacer este Disting,
¿no?
Porque no podríamos
distinguir que el director
no se repite
si tenemos otro título,
¿no?
O sea,
sería mucho más complicado.
Para eso luego veremos
que son Group By,
¿vale?
Cómo podemos agrupar,
cómo podemos hacer
diferentes cosas.
Pero en este caso
sí que podemos hacer
un Disting de los directores
porque se estarían,
si no,
repitiendo.
Esto es súper interesante
y bastante importante
a la hora de optimizar
tus bases de datos,
¿vale?
¿Por qué?
Porque imagínate
que tú haces un Select Director
de un millón de películas
y vais a tener
un montón de directores
y muchas veces
si esto lo iteras
en un array
y todo este tipo de cosas,
vais a necesitar
hacer un Disting,
¿vale?
Para evitar.
Lista las últimas
cuatro películas
que han sido lanzadas
por Pixar
y entonces que la ordenemos
de más reciente,
de la más reciente,
vale,
o sea,
de la más nueva
a la más vieja.
Ok,
pues aquí lo que vamos
a tener que cambiar,
vamos a quitar el Disting,
esto no lo necesitamos ya,
le voy a poner un Select
con asterisco,
pero porque entiendo
que no sé
qué es lo que me piden,
a lo mejor me lo está pidiendo todo,
de películas,
¿vale?
El Order By
lo vamos a cambiar,
le vamos a decir
que lo queremos
por el Year
de forma descendiente,
¿no?
De mayor a menor
y como nos dice
que tienen las últimas cuatro,
Limit 4,
ya está.
Con esto hemos recuperado
las últimas cuatro películas
de Pixar
y las hemos ordenado
correctamente.
Con otra cosa,
dice lista
las cinco películas
ordenadas
alfabéticamente,
bueno,
pues entonces
el título,
vamos a ordenar
alfabéticamente,
las primeras
cinco
y ya lo tendríamos,
¿vale?
Todas las películas
ordenadas por título
de forma ascendente
y limitamos a cinco.
¿Vale?
Tened en cuenta una cosa,
si no ponéis
Ask o Desk,
por defecto
es ascendente,
¿vale?
Por eso a veces
lo voy a ir sin poner nada.
Y luego,
lista las próximas
cinco películas
de Pixar
ordenadas
alfabéticamente.
Bueno,
esto sería exactamente
lo mismo,
fijaos,
esto sería una paginación,
esta sería la primera página,
imagínate que quiero
recuperar la siguiente página,
pues la siguiente página
tenemos que hacer
Offset 5,
porque las primeras cinco
ya la hemos visto,
en la siguiente página
queremos la siguiente cinco,
la página 2
ya sería 10,
en la página 3
sería 15,
¿no?
Tenemos que ir saltando
hasta que no tengamos resultados.
Simple Select Queries,
vale,
este es de,
este es como para repasar
un poco lo que hemos hecho
y complicarlo un poco más.
Lista todas las ciudades
de Canadá
y sus populaciones,
o sea,
sus populaciones,
su población,
sus populaciones,
que lo he pensado en inglés
y lo he dicho en español.
Vale,
entonces,
de Canadá,
pues World Country
igual a Canadá,
¿vale?
Ordena a todas las ciudades
en los Estados Unidos
por su latitud
de norte a sur.
Hostia,
no sé,
no sé cómo es el tema
de la latitud de norte a sur,
pero bueno,
lo vamos a imaginar.
A ver,
imagino que aquí usa,
o como,
a ver cómo era el nombre
de Estados Unidos,
United States.
Vale,
World Country
y para cambiar un poco,
para que no se nos olvide
cómo era,
vamos a poner
like United States,
¿vale?
¿Veis?
Esto lo saca,
aunque lo correcto sería
evitar esto,
pero,
o sea,
poner el igual,
pero bueno,
para que nos acordemos
del United States.
Vamos a poner el World.
Una cosa interesante de SQL
es que podéis hacerlo
en más de una línea.
Lo importante es que las sentencias
las terminéis con punto y coma,
¿vale?
Entonces podéis poner el Select aquí,
podéis poner el From aquí,
el World aquí,
lo podéis poner cada uno
en una línea
y se entiende bastante mejor.
Vamos a poner el Order By,
no sé,
Latitude,
Latitude,
Latitude,
el Country,
lo vamos a poner en minúscula,
Latitude y Descendiente.
De Norte a Sur es Descendiente,
la Latitude.
Y ya lo tendríamos.
Ahora,
lista de todas las ciudades
del Este de Chicago,
¿cómo?
Ordenados de Este a Oeste,
vale,
Chicago Longitude,
me imagino que Chicago 87,
vale,
este es complicado,
o sea,
no es complicado de hacerlo,
pero es complicado como de verlo.
Entiendo que,
tendríamos que mirar,
que la Longitude,
Longitude,
sea mayor o igual,
o sea,
menor,
menor,
vale,
y esto lo vamos a poner
on country,
porque,
ah,
bueno,
no hace falta que sea de Estados Unidos,
o sea,
que esto lo quitamos,
no sé si esta es la,
ah,
mira,
este,
esto sea Chicago,
vale,
o sea,
que entiendo que sería menor,
¿no?
O sea,
sería esto,
ordenado de Oeste Longitude
al Oeste de Chicago,
a ver,
no sé si es que el número
es un poco,
ah,
he puesto este,
y este ha funcionado,
87.68,
ahora entiendo,
ahora entiendo,
claro,
ahora entiendo,
como estaba Chicago,
en realidad tenía que ser como más,
o sea,
tenía que ser este,
porque claro,
si no estaba contando el propio Chicago,
yo entiendo que no tenía que pedir el,
o sea,
no tenía que llegar Chicago,
tenía que ser menos que Chicago,
y estas eran las ciudades que están al Oeste de Chicago.
Selecciona las dos ciudades más grandes de México,
por su población,
yo también,
por su población,
vamos,
con la longitud,
vale,
donde el country,
country sea igual a México,
ah,
no sé si estaba en mayúscula,
order by population,
y limit,
desk,
vale,
porque hay decremental,
o sea,
seleccionamos los todos,
de todo esto,
el país que sea México,
la población que vaya de más a menos,
y limitamos dos,
y lista,
tercera y cuarta,
ciudad más grande,
de Estados Unidos,
y su población,
pues,
population,
city,
country,
United States,
United States,
y quiere la tercera y la cuarta,
por lo tanto,
el offset tiene que ser de dos,
¿por qué?
Porque nos saltamos el primero,
el segundo,
y ya con esto nos da la tercera y la cuarta,
Chicago y Houston.
Vamos con los joins,
que esto es una de las cosas que más le cuesta a la gente,
y que se vuelve loca,
y que,
ah,
Dios mío,
los joins,
los joins,
los joins.
Los joins es,
en realidad,
algo bastante sencillo,
y es el hecho de cuando hacemos relaciones entre dos tablas,
queremos poder recuperar datos de una tabla,
y poder llevárnoslo a otra,
o sea,
queremos hacer esa relación de decir,
tenemos la tabla usuarios,
tenemos la tabla tweets,
y queremos realmente traernos la información,
para poder hacer una introspección de los datos,
y machearlo,
y decir,
quiero todos los datos de todas estas tablas,
y no tenerlos separados.
Ahora bien,
¿qué pasa con los joins?
Que hay diferentes joins.
Hay veces,
que vamos a querer traer los datos,
de derecha a izquierda,
independientemente,
si los datos existen a la izquierda.
Por ejemplo,
tenemos todos los usuarios,
tenemos todos los tweets,
pero hay veces que a lo mejor,
hay usuarios que no han creado tweets,
y aún así,
queremos que estén en los resultados,
y que a lo mejor,
sus tweets sean nuls.
O al revés,
queremos que a lo mejor,
hay tweets que no han hecho usuarios,
y queremos llevarlos a otro sitio.
O no,
hay veces que queremos que solo salgan resultados,
si realmente,
hay en las dos tablas,
y tienen una conexión.
Entonces,
dependiendo del tipo de unión,
de los datos que queramos hacer,
vamos a ver,
que vamos a tener que utilizar diferentes joins.
El primero,
y más importante,
es el inner join,
que es,
esos datos,
que queremos,
que estén en las dos tablas,
¿vale?
y que no tengamos ningún tipo de nul.
Tú imagínate que tienes tweets,
y tienes usuarios.
El inner join,
lo que va a querer,
es encontrar,
cuáles son esos datos,
que machean los dos.
Y por lo tanto,
si hay usuarios,
que no tienen tweets,
no los vamos a querer mostrar.
Muchas veces,
lo más fácil,
para ver el tema de los joins,
si buscáis,
join SQL,
vas a ver,
todos los diferentes tipos de joins.
Hay un montón de joins.
Pero,
el más importante,
suele ser,
este de aquí.
Porque este es el que se suele utilizar más,
a la hora de hacer relaciones.
Lo vamos a ver con los ejemplos directos,
no os preocupéis,
y vais a ver un poquito,
cómo es la sintaxis.
Pero la sintaxis,
vais a ver,
que igual que pasaba antes,
pues vamos a tener que poner,
en mitad de nuestras consultas,
le vamos a tener que indicar,
de qué tabla queremos traer los datos,
y sobre todo,
cuál es la relación,
que tienen los datos.
Porque para poder,
traernos los datos de otra tabla,
tenemos que decirle,
bueno,
pero los usuarios y los tweets,
cómo se relacionan.
Y realmente,
dónde está,
ese momento en el que,
hay un enlace,
y podemos extraer esos datos,
para meterlos en la misma fila.
Así que lo vamos a ver.
Aquí podemos ver,
que tenemos dos tablas,
tenemos movies,
y tenemos box office.
Tenemos dos tablas.
En estas dos tablas,
ahora vamos a querer hacer,
relaciones de datos.
Quieren que encontremos,
las ventas domésticas e internacionales,
para cada película.
Aquí en las películas,
tenemos la idea,
el título,
el director,
el año,
la longitud en minutos.
Y en el box office,
tenemos aquí un movie ID.
Aquí podemos ver la relación.
Ahora mismo,
la relación que vemos es que,
las ideas de las películas,
las tenemos aquí referenciadas,
en box office,
es como lo que sacaron de dinero,
en la cartelera.
Tenemos aquí como la idea,
la película 5,
que sería aquí,
Finding Nemo,
tenía una puntuación de tal,
hizo este dinero,
y internacionalmente,
hizo este dinero.
Y ya nos está pidiendo,
de que queremos sacar el dinero,
de cada una de las películas.
Por lo tanto,
tenemos que recuperar,
cuánto hizo Toy Story,
gracias a preguntarle,
a otra tabla.
Lo primero que vamos a sacar,
es el title,
¿vale?
Así que primero,
nos quedamos con el title.
Esto lo vamos a hacer,
from movies,
esto perfecto,
pero a la hora de hacer,
la relación,
le teníamos que decir,
de dónde sacamos los datos,
¿no?
Pues le vamos a decir,
que vamos a hacer,
un join,
de box office.
Claro,
al hacer el join,
así sin decirle,
ninguna condición,
fíjate lo que ha pasado.
Lo que está pasando,
es que está haciendo,
por cada fila,
que tenemos aquí,
está repitiendo,
la fila que tenemos aquí,
porque no estamos haciendo la relación.
Entonces,
aquí de Toy Story,
habrá tantos Toy Stories,
como cada fila que hay aquí,
porque no hemos hecho una relación,
y por lo tanto,
está repitiendo constantemente los datos.
Esto no es lo que queremos,
de hecho,
mira,
lo podéis ver así,
movie ID,
si hago esto,
¿veis?
Por Toy Story,
por cada título de Toy Story,
lo que está haciendo es,
sacar cada una de las filas,
no hemos hecho la relación.
Tenemos que decirle,
cómo lo tiene que unir,
cómo tiene que hacer la relación.
Así que decimos,
oye,
quiero que me hagas el join,
que por cierto,
en algunos motores,
encontraréis que es inner join,
¿vale?
Utilizar como queráis,
inner join,
y le tienes que decir,
vale,
cuando me hagas el inner join,
me lo tienes que hacer,
con la ID,
que sea igual,
al movie ID,
¿vale?
Y ahora sí,
ya hemos hecho la relación,
de las dos tablas.
Oye,
seleccioname el título,
y el movie ID,
de movies,
y tienes que traerme la información,
de la tabla books office,
pero ten en cuenta,
que me tienes que hacer una relación,
en la que esta película,
con esta ID,
se relaciona con el movie ID,
por lo tanto,
esta fila que tenemos aquí,
esta que tenemos aquí,
está relacionada,
con esta que tenemos aquí,
y por lo tanto,
una vez que ha hecho,
este nexo,
ahora sí,
vamos a poder recuperar,
la información que tenemos aquí,
como por ejemplo,
que no me hace scroll,
ahora,
¿vale?
Domestic sales,
¿vale?
Ya podemos sacar el domestic sales,
y el international sales,
¿vale?
Y ya lo tendríamos,
¿vale?
Ya tenemos el primero,
ya hemos encontrado,
el título de cada una,
la ID de la película,
esto lo podemos sacar,
porque esto no nos lo pedían,
el domestic sales,
international sales,
pero como puedes ver,
lo que está haciendo un join,
en este caso,
es que está buscando exactamente,
la información de cada fila,
o sea,
está buscando de esta idea,
y lo está relacionando,
con la idea que tiene aquí,
a la derecha,
por ejemplo,
aquí este 5,
este finding demo,
pues lo que está diciendo es,
¿vale?
Este finding demo de aquí,
la relación está con este de aquí,
y estamos sacando esta información,
y ya cuando hagas un select,
ya eres capaz,
de hacer la introspección,
de los datos de esa tabla,
una cosa importante,
es que verás,
que hay veces,
que las columnas,
se pueden llamar igual,
y para eso,
tendrías que utilizar,
nombres de tablas,
o sea,
puedes decir,
movies,
que sea M,
y entonces hacer,
M.title,
M.title,
B.title,
Domestic Sales,
para referirte,
a cada una de las tablas,
esto si tienes,
algún tipo de colisión,
de nombre de columna,
ahora nos dice,
mostrar,
los sales numbers,
para cada película,
que haya hecho mejor,
internacionalmente,
que domésticamente,
joder,
no está mal,
el inner join,
este,
va a ser exactamente igual,
o sea,
esto ya os puedo asegurar,
que va a ser exactamente igual,
solo que vamos a tenerle,
un where,
le vamos a decir,
donde,
International Sales,
haya sido mejor,
que Domestic Sales,
vale,
o sea,
que ya le ponemos un where,
y ya tenemos solo las películas,
que han hecho mejor internacionalmente,
que domésticamente,
y ahora,
todas las películas,
que estén ordenadas,
por sus ratings,
claro,
una vez que ya tienes,
la información de la otra tabla,
también puedes ordenar,
a través de datos,
que tienes aquí,
o sea,
en este caso,
Finding Nemo,
como ya ha hecho el inner join,
ya sé que Finding Nemo,
el rating que tiene,
porque tenemos la conexión aquí,
es 8.2,
así que podemos quitarle el where,
order by rating,
desk,
vale,
y ya estaríamos listando,
todas las películas,
por su puntuación,
ok,
se pueden concatenar,
se puede concatenar todo,
todo se puede concatenar,
en SQL,
todo,
tú puedes poner SQL,
dentro de SQL,
o sea,
selects dentro de selects,
puedes concatenar,
tanto senior joins,
como quieras,
de hecho,
seguramente los vas a necesitar,
vas a tener,
todo se puede concatenar,
es una salvajada,
todo y más,
los outer joins,
son estos,
que ya vamos a tener más problemas,
porque nos vamos a traer datos,
que a lo mejor,
no son completos,
podemos tener aquí,
el left,
el right,
o el full,
vale,
el left sería,
para traer,
hacia el de la izquierda,
la tabla de la izquierda,
el right sería,
para traerlo a la derecha,
y el full sería,
traer para los dos,
mira,
aquí tendríamos,
por ejemplo,
el left join,
imagínate,
esta es la tabla users,
y tendrías aquí,
distar todos los usuarios,
y esta sería la tabla tweets,
pues imagínate,
si haces un left join,
cuál es el problema,
que si tienes mil usuarios,
y tienes 500 tweets,
vas a tener,
mil elementos,
y no importa,
que no todos los usuarios,
hayan hecho un tweet,
porque independientemente,
vas a tener,
todos los usuarios,
mostrados,
que es diferente al inner join,
porque solo te mostrarían,
los usuarios,
que han hecho el tweet,
luego tendrías el right join,
que haría todo lo contrario,
vale,
tendrías todos los datos,
que aparecerían en la derecha,
y luego tendrías el full,
que lo que te estarían trayendo,
que es este de aquí,
te estarían trayendo,
todos los datos,
vamos a ver,
find the list of all buildings,
that have employees,
vale,
tenemos aquí,
una tabla de buildings,
tenemos una de employees,
hostia,
pero este no necesita join,
entiendo,
porque mirad,
este de encontrar,
este es trampa,
porque encontrar,
todos los edificios,
que tienen employees,
lo que podríamos hacer,
es buscar aquí,
building,
from employees,
vale,
hay building,
building,
vale,
from employees,
y aquí hacer un distinct,
check,
vale,
entonces aquí tendríamos,
todos los edificios,
que tienen empleados,
porque,
porque mirando solo,
la tabla de empleados,
que esto es otra cosa,
súper importante,
siempre que podáis evitar,
hacer joins,
evitarlos,
así que este es un buen ejemplo,
de cómo evitar hacer joins,
porque no tiene sentido,
luego,
encuentra todos los buildings,
y su capacidad,
aquí sí que vamos a necesitar,
hacer un join,
porque,
ahora sí,
dice,
la capacidad,
tenemos en esta tabla,
y aquí estamos mirando,
la tabla employees,
obviamente,
podríamos hacer esto,
vale,
podríamos hacer esto,
y,
find the list of buildings,
under capacity,
claro,
yo entiendo,
que podríamos hacer esto,
y ya está,
y ya tenemos la capacidad,
o sea,
entiendo,
que hay que hacerlo todo,
utilizando left join,
o sea,
todos los ejercicios,
hay que hacerlos,
utilizando left join,
por ejemplo,
el de,
el primero,
mira,
voy a resetearlo,
vale,
lo que podríamos hacer,
es,
seleccionar,
todos,
el building name,
que tenemos aquí,
el building name,
building,
ah no,
building,
vamos a seleccionar,
building name from buildings,
entonces,
lo que tenemos que hacer,
es un join,
de employees,
join employees,
on,
building name,
es igual a building,
a ver,
claro,
lo importante,
claro,
ahí está,
ahora entiendo por qué,
por qué es esto,
vale,
ahora entiendo por qué es esto,
por qué quieren que lo hagas con el left join,
cuando hacéis el left join,
fijaos que,
si yo hago un select,
de building name,
y role,
fijaos,
que,
el role,
de algunos,
está nul,
está vacío,
¿por qué está vacío?
porque estamos haciendo un left join,
lo que estamos haciendo,
es,
independientemente,
de que el building,
uno,
W,
tenga,
empleados,
lo estamos mostrando igualmente,
estamos trayéndonos los datos,
por eso es un left join,
porque,
todos los datos que tenemos en esta tabla,
van a ser incluidos,
independientemente,
de que,
haya un nexo,
con los datos que tenemos aquí,
por ejemplo,
el,
1,
W,
no tiene datos,
no hay empleados aquí a la derecha,
pero como hemos hecho un left join,
la tabla de la izquierda,
está trayendo todos los datos,
por eso,
tanto el 2E,
como el 1W,
ves que,
aquí en roll,
no hay ninguno que tenga el roll este,
está en null,
pero como es un left join,
fijaos en la diferencia,
si yo pongo un join,
desaparecen,
el join,
era el inner join que hemos hecho antes,
si pongo un left join,
aparecen,
el left join,
lo que hace es,
todos los datos de la tabla izquierda,
se los va a traer,
independientemente,
si aparecen en la tabla de la derecha,
que estamos haciendo el join,
esa es la,
la diferencia clave,
que tiene,
y el right join,
sería al revés,
que se traería todos los de la derecha,
y el full join,
sería,
que se traería los de la izquierda,
y los de la derecha,
independientemente,
y yo creo que en este ejercicio,
lo que quiere justamente,
es que digas,
vale,
y ahora que tienes esto,
tienes que hacer dos cosas,
lo primero,
que donde el roll,
is not null,
vale,
vale,
donde no sea null,
y además,
teníamos que hacer un distinct,
del building name,
y podríamos quitar el,
el roll,
el roll este,
podríamos quitar el roll,
y tal,
y ya está,
ahora ya con el distinct,
con,
utilizando el left join,
ya os digo,
que la buena,
era la que hemos hecho antes,
pero bueno,
entiendo que forzándonos,
a utilizar el left join,
tendría que ser así,
dice,
encuentra la lista,
de todos los buildings,
y su capacidad,
a ver,
de todos los buildings,
y su capacidad,
entiendo que si hago el distinct,
y quito el roll,
claro,
aquí ya tengo todos los buildings,
y si queremos su capacidad,
pues ya está,
ponemos aquí capacity,
y ya lo tendríamos,
y luego,
listar todos los buildings,
y los roles de employees,
de cada building,
incluyendo los buildings vacíos,
a ver,
vamos a traernos,
el distinct building name,
y vamos a traernos,
el roll,
from buildings,
¿vale?
no tengo la columna roll,
todavía,
cierto es,
porque no hemos hecho,
el left join,
de,
nunca me acuerdo,
employees,
employees,
on building name,
sea igual,
a building,
claro,
como decía,
incluyendo los vacíos,
por eso,
lo teníamos aquí,
y aquí,
pues no tiene roll,
sería nul,
y ya está,
pero fijaos aquí,
otra vez de nuevo,
la diferencia,
si quito el join,
vais a ver que desaparecen,
los que están vacíos,
vale,
entiendo que ahora,
se queda aquí con los nuls,
normalmente,
hay que evitar los valores nuls,
en la base de datos,
siempre que se pueda,
hay que evitar los valores nulos,
a veces se utilizan,
pues,
campos de texto vacío,
y cosas así,
el problema es que a veces,
el nul,
no es que sea una mala práctica,
sino que a veces,
es un poco complicado,
a la hora de hacer el,
el wear,
porque entonces,
ya tienes,
es nul,
es no nul,
es vacío,
no sé qué,
solo que no,
no hagáis siempre nulos,
no hagáis siempre nulos,
porque es un rollo,
cuando tengan las condiciones,
y a veces,
quieran ver si es nulo,
y a veces,
quieran ver si es vacío,
y a veces,
quieran mirar,
si realmente,
tiene una cadena de texto dentro,
vale,
y cosas así,
que es un poco complicado,
encuentra el nombre y el rol,
de los empleados,
que no han sido asignados,
a un building,
vale,
este es sencillo,
vale,
encontramos,
el nombre y el rol,
de from employees,
from employees,
employees,
where,
que no han sido,
o sea,
no han sido asignados,
significa que el building,
es que no sé por qué a veces el,
vale,
o sea,
que,
donde,
where,
building,
is nul,
vale,
aquí lo tenemos,
y ahora,
encontrar los nombres,
de los buildings,
que no tienen empleados,
los nombres,
que no tienen empleados,
tenemos que encontrar,
una cosa que me gusta,
muchas veces de SQL,
que al final te acostumbras,
es cuando tienes que hacer,
como el primer select,
y que es lo que te pide,
vale,
primero lo que te pide,
es el nombre de los,
el building name,
por lo tanto,
esto lo tenemos que tener clarísimo,
el building name,
entonces,
from buildings,
luego,
como dice que no tenga empleados,
aquí es donde entra en juego,
el left join,
entonces,
le vamos a decir,
de los empleados,
que,
el building name,
sea igual al building,
vale,
entonces,
aquí ya tenemos el building name,
building name,
vale,
de los empleados,
tatata,
donde el,
role is null,
que no tiene empleados,
vale,
y ya tendríamos aquí,
ya tendríamos el building name,
de los que no tienen empleados,
vale,
bueno,
realmente,
claro,
al final es como la única forma que podemos hacer,
porque con el left join,
es que estamos trayendo,
todos los nombres de los,
de los buildings,
y claro,
porque de aquí no lo podemos sacar,
porque son justamente los que no tienen empleados,
así que ahí ya lo tendríamos,
¿qué hace el on?
El on justamente es el que hace la relación entre la tabla donde estamos buscando y de la que tenemos que traer los datos,
es efectivamente,
es como el where del join,
donde le estamos diciendo,
oye,
de la tabla buildings,
esta,
hazme la conexión entre el building name que sea igual al building de aquí,
vale,
y aquí es donde estamos haciendo esta conexión,
entre esto y esto de aquí.
Os quiero un montón,
espero que lo hayáis disfrutado,
que hayáis aprendido algo nuevo con el tema de SQL,
el es súper importante SQL,
que esto os haya ido de inicio,
y más adelante haremos una segunda parte,
seguramente enfocada a MySQL,
para que veáis que,
un caso práctico,
y a lo mejor,
lo que estoy pensando es que podríamos hacer la base de datos,
por ejemplo,
de Netflix,
y crear la base de datos de Netflix,
y a partir de ahí,
ir viendo más consultas y cosas así,
las relaciones y tal,
y hacerla desde cero,
y creo que puede estar muy chulo.