¿Qué tal? ¿Cómo estás? Espero que fantásticamente, preparadísimo, espero, porque hoy vamos a crear una base de datos desde cero, paso a paso,
cómo crear con MySQL la base de datos de Twitter. No sé exactamente hoy, pero antes al menos utilizaba MySQL para guardar toda su información.
Vamos a ir creando tablas, los nexos, cómo deben comunicarse las llaves, qué estrategia podríamos seguir para hacerlo.
Vamos a hacer consultas, actualizaciones, insertar datos, joins, vamos a hacer subconsultas, vamos a ver triggers.
Obviamente no es toda la base de datos de Twitter, pero vais a ver que las ideas están ahí y de hecho puede ser un ejercicio maravilloso
que lo que nosotros dejamos como base, tú lo lleves al siguiente nivel.
MySQL, para el que no sepa lo que es, por si tienes alguna duda, sistema de gestión de base de datos relacionales.
Se utiliza ampliamente por todos los sitios para almacenar, organizar, administrar, grandes cantidades de datos de manera eficiente
y fue desarrollado en su día por unos programadores suecos y después más adelante lo adquirió Oracle.
Se utiliza para aplicaciones web, sistemas de gestión de contenido como WordPress, que lo utiliza por detrás, comercio electrónico, e-commerce.
Os recuerdo, os vais a Downloads para instalarlo.
Si tenéis Windows, tenéis que instalaros la versión, a ver si es que, a ver, veis que tiene Enterprise, no sé qué, es que Oracle es rata hasta el final.
Fijaos que aquí tiene este download súper pequeñito, separado y todo esto.
Es que la versión que tenéis que instalar es esta de aquí, MySQL Community, ¿vale? Esta de aquí.
Si tenéis Windows, es súper sencilla, es esta de aquí, Installer for Windows, perfecto, ahí os lo instaláis todos y os instaláis el Workbench y también la base de datos con el motor que queráis, ¿vale?
Si lo que tenéis es MacOS, lo que tenéis que instalar es el MySQL Workbench y yo os recomiendo que os instaléis de forma totalmente separada a lo que sea el motor.
Podéis utilizar, por ejemplo, si es MacOS, tenéis Brew o directamente yo os recomiendo este de aquí.
Y si ya tenéis otra aplicación, pues otra aplicación. Pero a mí esta aplicación me encanta. De hecho, la vais a ver ahora, ¿eh?
Es una aplicación totalmente gratuita, sencilla. Le das aquí al más.
Aquí podéis elegir qué tipo de servicio queréis levantar, un Postgre, MySQL, un Redis y esto lo levanta, así y ya está.
Y aquí podéis poner la versión que queráis, que también os recomiendo que utilicéis la versión, si tenéis en Silicon, las de ARM, que van más rápido.
Pero bueno, yo ya tengo una creada, que es esta de aquí, que le he puesto Untitled, ¿ves? Y además que puedes entrar directamente.
Pero le voy a poner Start para que levante el proceso, ¿vale?
Y a partir de aquí, ahora sí, vamos a empezar con lo nuestro.
Ya que esto está levantado, lo único que tenéis que hacer es entrar en Workbench, MySQL Workbench, que será lo que habéis instalado ya.
Y esta aplicación tiene una cosa bastante chula, que directamente te detecta las conexiones MySQL, ¿ves?
Aquí te está detectando la conexión MySQL y te dice, vale, pues esta.
Si le has puesto password, te pedirá el password. Si no le has puesto password, pues podrás entrar directamente.
Pero aquí ya te va a entrar todas las bases de datos que tengas levantadas. Simplemente le das un clic, y ya estamos aquí dentro.
Ya tenemos acceso a nuestra base de datos. Aquí vamos a estar trabajando ya todo el día.
Aquí vamos a crear la base de datos de Twitter desde cero y vamos a ir chino chano, ¿vale?
Lo primero que podríamos hacer es ver qué bases de datos tenemos. Para eso hay un comando que se llama Show Databases.
Os voy a explicar también un poco la UI. Fijaos aquí que tenéis, bueno, aquí tenemos una pestaña, podéis hacer tantas queries como queráis.
Podéis abrir como queries, guardar las queries. Me encanta que todavía salga un floppy disk, un diskette.
Esto, la gente que sois del 2000, por ejemplo, que habéis nacido del 2000, ¿esto lo entendéis? ¿Esto lo entendéis?
¿Sabéis qué es esto? Porque esto no tiene mucho sentido, ¿verdad? O sea, es como súper raro para vosotros. No tiene ningún sentido.
Bueno, lo importante son sobre todo estos dos. Mira, este rayito es para ejecutar lo que tenga seleccionado o todo el script, ¿vale?
En este caso, si le doy, pues vamos a ejecutar esto. Y esto es para ejecutar la línea donde está el cursor.
Son estas dos las más importantes. Esto sería para parar, en el caso que estés haciendo una consulta y quieras parar.
Estas son las más importantes que vamos a tener. Así que si le damos a este botoncito, aunque ahora te diré un shortcut, ¿vale?
Para que no le des. Si le das, ves, aquí tenemos la respuesta. Y nos ha dicho, mostrar las bases de datos.
Nuestro motor de base de datos, en este caso MySQL, cuando hemos entrado directamente, fijaos que ya tiene base de datos, ¿vale?
Ya tiene base de datos donde tiene termas del sistema, un esquema sobre performance, la información de la propia base de datos,
información del esquema. Y estos esquemas, que los podríamos ir preguntando ahí constantemente, ¿no?
Podríamos mirar qué hay dentro. También lo podéis mirar visualmente. ¿Veis aquí la pestaña esquemas?
Pues podéis darle aquí. Y aquí, aunque es verdad que solo veis la de sys, porque las otras se supone que son ocultas,
aquí tenéis la posibilidad de ir viendo, pues ves, tablas, ver en sysconf.
Aquí podríais ver las columnas que tenéis. Esto significa que ya podríais pedir información, por ejemplo, de estas columnas.
Aquí, vale, si le dais al botón derecho, le doy select rows limit mill. Os va a crear otra query para ver qué es lo que hay dentro.
Y aquí tenéis, pues ya la sintaxis de la consulta. Selecciona todas las columnas de esta tabla.
Nosotros vamos a crear nuestras tablas, pero solo para que veas que ya tiene información la base de datos.
Nosotros no hemos creado nada todavía y ya tiene información. Tiene sus propias bases de datos.
Cuando hablamos de bases de datos, hay que entender motor de bases de datos, que va a tener la colección de bases de datos,
y vamos a poder tener más de una. Nosotros vamos a crear una base de datos de Twitter,
pero, como veis, ya tenemos cuatro bases de datos y vamos a tener una más que vamos a crear nosotros.
Así que vamos a crear ya nuestra primera base de datos. Vamos a crear create database y le ponemos nombre a nuestra base de datos.
Para crear una base de datos, tendríamos que hacer create database y el nombre de la base de datos.
Le damos al enter y ya hemos creado la base de datos. Ahora no aparece aquí, pero si le dais a este iconito que tenéis aquí de refresh,
¿veis? Aquí ya tenemos nuestra base de datos. No solo ahora tenemos la de sys, sino que también tenemos esta.
Pero fíjate que en las tablas, ahora mismo, está vacía. No tiene ninguna tabla.
Deberíamos empezar a crear una tabla. Pero antes de crear una tabla, si yo ahora aquí creo una tabla,
MySQL me va a decir, oye, ¿qué tabla? O sea, ¿dónde quieres crear la tabla?
¿En qué base de datos quieres crear la tabla?
Le tenemos que decir qué base de datos de las que hay disponibles queremos utilizar.
Mira, vamos a poner aquí el show database otra vez.
Y os voy a explicar un truquito para no tener que darle otra vez a este botoncito.
Que os recuerdo, son dos botones. El de la izquierda ejecuta todo lo que tengáis o lo que tengáis seleccionado.
Y el de la derecha solo ejecuta la línea en la que estáis.
Sin necesidad de venir aquí a ejecutar la línea, lo que podéis hacer es comando enter.
No sé si en Windows es control enter. Eso no lo sé. Pero creo que sí.
Entonces, si yo le doy comando enter, solo me va a ejecutar esta línea. ¿Vale?
No me ha ejecutado esta, solo me ha ejecutado esta.
Y aquí podemos ver la información de la base de datos.
Lo siguiente que tenemos que decir es, oye, quiero utilizar la base de datos de Twitter debe comando enter.
Y ahora no tenemos ninguna respuesta, pero sí que vemos aquí que nos vas dando un check.
¿Vale? Aquí tenemos como el output de cada una de las acciones.
Donde nos va a decir, oye, esto ha ido bien, esto ha ido mal, aquí hay un error.
¿Cuántas filas se han visto afectada cuando hemos hecho esto?
¿Vale? Estamos utilizando esta base de datos.
Vamos a crear nuestra primera tabla.
Porque si pensamos en Twitter, ya teníamos aquí una tabla que era la de usuarios.
La más importante, si lo piensas fríamente, todos los productos de la vida, todos los productos de la vida siempre nacen a través de, como mínimo, una tabla.
Mucha gente puede pensar que la tabla más importante sea tweets.
Pero no podrían existir los tweets si no tuviésemos usuarios, ¿no?
Porque serán los usuarios los que crearán los tweets.
Así que vamos por lo primero.
Lo primero que vamos a hacer es crear una tabla, ¿vale?
Y le decimos el nombre de la tabla, que es users.
Aquí vamos a tener como bastante información.
Vamos a ir revisando cada una y te iré comentando.
Lo más importante es que cada usuario tiene que tener un identificador.
Vamos a hacer un user ID.
Y aquí le podríamos decir de diferentes formas, ¿no?
Podríamos hacer que fuese un hash, que seguramente lo que tendría más sentido es que fuese una cadena de texto.
Pero nosotros, como lo estamos haciendo todo desde cero, también puede ser que tenga sentido que empecemos con algo autoincremental.
O sea, que el primer usuario sea uno, dos, tres, cuatro, tal.
Porque nos va a ayudar a identificar fácilmente los usuarios cuando los borramos, saber a quién nos estamos refiriendo.
Así que ponemos nuestra primera columna, nuestra primera información más importante es el ID del usuario.
Que va a ser un int.
Le vamos a decir que no es nul.
O sea, no puede ser nulo el user ID.
Y que se va a autoincrementar.
Aquí tendríamos el nombre de la columna, tendríamos el tipo de la columna.
Aquí tendríamos como restricciones que podría tener la columna, como que no puede ser nul.
Y aquí estamos poniéndole como un valor por defecto.
Más que un valor por defecto es la función que se debe ejecutar cuando se está creando un nuevo usuario.
Automáticamente lo que va a hacer la base de datos es decir, vale, pues el usuario si se ha quedado en uno, el siguiente será dos, tres, cuatro.
O sea, que muchas veces MySQL, PostgreSQL, SQLite, esto es algo bastante común en todas.
Porque el autoincrement es lo más típico del mundo.
Pues son como funciones internas que ya te van a funcionar para que lo hagan automáticamente y tú no te tengas que preocupar absolutamente de esto.
Luego tendríamos el user handle, por ejemplo, arroba mi dudé.
No va a ser un entero, esto podría ser un varchar.
Y fíjate que tenemos aquí un autocomplete con un montón de cosas que ya te dice todas las cosas que pueden ser.
Puede ser viking, binario, podéis guardar incluso datos binarios, podéis guardar fotos en la base de datos.
No es lo más recomendable, pero se puede hacer.
Boleanos, que pueden ser un carácter, una fecha, decimales, punto flotante, enteros de diferentes tamaños, también strings, o sea, hay de todo.
En este caso vamos a poner varchar.
Varchar es como la forma más típica en la que se hacen cadenas de texto, ¿vale?
Pero cadenas de texto acotadas en longitud.
¿Qué quiere decir esto?
Por ejemplo, normalmente este handle no puede ser tan largo como el usuario le dé la gana.
O sea, aquí no puede ser, pues, super Miguel Ángel, Durán García, no sé qué, no sé cuánto, bla, bla, bla, sino que tiene como un límite.
Límites que hace que así la gente no se pase.
Vamos a ponerle nosotros un límite 100, me parece mucho.
Vamos a ponerle 50.
También no puede ser nul, porque todos, todos los usuarios tienen que tener un handle.
Y una cosa también importante, otra restricción, es que tiene que ser único.
¿Por qué tiene que ser único?
Porque no hay dos usuarios que tengan el mismo handler, si no, estamos jodidos, ¿vale?
Y esto es muy interesante porque tenéis que saber que a veces podemos tener el identificador del usuario por un lado,
y por otro lado podemos tener un campo que aunque no sea su identificador, sea único también.
Y esto, pues, tenemos otro ejemplo también, el email address.
El email address, que vamos a poner también 50 chars, no puede ser nul y también tiene que ser único.
Todos los usuarios tienen que tener una dirección de correo y si no permitimos que se puedan repetir, podemos poner únicas.
Esto, lo que se le llama en inglés son como constraints, o pueden ser más como restricciones a la hora de hablar de nuestra base de datos.
Hay cierta información que podemos decir que sea única, que no sea nul y todo esto.
Vamos a poner el first name, vamos a poner un bar chart también de 5, vamos a ir cambiando porque si no va a ser todo igual, ¿no?
No nul, last name, pues bar chart también, y aquí vamos a poner 100, no nul.
También lo mismo con el font number, ¿no?
Font number, aquí le podríais poner, por ejemplo, también, pues el bar chart, aquí le podéis poner el chart de 10, más pequeño,
y ponerle también que sea único porque no se pueden repetir.
El birthday, mira, voy a enseñar una muy interesante, created that.
Cuando creamos un usuario, queremos saber cuándo el usuario se ha creado, ¿no?
Y obviamente esto no es una cosa que vamos a querer que el backend le pase el timestamp y tal,
sino que queremos que la base de datos de forma interna y automáticamente ya le añada cuál es el timestamp de esa propiedad, ¿no?
Que es decir, oye, ¿cuándo se creó la base de datos?
Y esto ya tiene un tipo que se llama timestamp, o sea, directamente ya tiene un tipo definido para cuando te refieres al tiempo.
Podemos decir que no puede ser null, pero claro, si no puede ser null, o se lo pasamos o le damos un valor por defecto.
Así que nosotros le vamos a dar el valor por defecto y le vamos a decir que, por defecto, el valor que tiene esto podría ser now, el valor de ahora, ¿no?
O sea, y el now, como ves aquí, es otra función que tendría MySQL de forma interna,
que lo que va a hacer es que cada vez que se inserte un usuario en esta tabla, por defecto, si no le decimos el created add,
vamos a tener este valor ya en esta columna.
Veremos, ¿no? Cuando añadamos un nuevo usuario y veremos cómo le está poniendo automáticamente el timestamp,
aunque nosotros no se lo digamos.
Antes de terminar, y esto es súper importante cuando creamos las tablas, es que tenemos que saber cuál es su key primaria.
¿Qué es una key primaria?
Mira, pensemos en esta tabla de usuarios que tenemos aquí, ¿vale?
Ves que tenemos aquí id1. Obviamente, la llave primaria sería como el campo o conjunto de campos,
porque puede ser más de un campo, que identifica de manera única e inequívoca a un elemento de la tabla.
Pero ojo, ojo cuidado con esto, porque hay gente que podría decir,
oye, ¿y por qué el username no es una llave primaria, no?
Y no puede ser una llave primaria porque no solo, y esto es súper importante, ¿vale?
No solo tiene que ser una forma de un identificador único, sino que también tiene que ser inmutable.
O sea, tiene que ser una clave que no vaya a cambiar una vez que sea asignado.
Una vez que le hemos dicho que Elon Musk tiene el identificador 1, este identificador no puede cambiar.
¿Qué pasa con el username?
El username no puede ser el primary key porque sí que es verdad que es único, pero no es inmutable.
Tú puedes venir a Twitter y te puedes cambiar este handle de midudev, lo puedes cambiar por midu, midu, midu lo que sea.
Lo puedes cambiar.
Entonces ya no sería inmutable.
Una vez que sea asignado, lo puedes cambiar.
Y por lo tanto, no garantiza que ese registro sea identificable de manera consistente.
O sea, es súper importante la diferencia.
El user id sí que lo puede ser porque el user id no lo vamos a cambiar nunca.
Vamos a tenerlo que no es nulo.
Una primary key no puede ser nula.
Eso es obviamente.
Segundo, tiene que ser un identificador único.
Tiene que tener la unicidad.
Y lo tercero es que tiene que ser inmutable.
O sea, no se puede cambiar ya para jamás.
Entonces por eso muchas veces tiene sentido que sea la id del usuario.
Porque la id del usuario es un registro más interno que nunca va a cambiar.
Pero en cambio, el nombre del usuario sí que puede cambiar.
Por ejemplo, tampoco podría ser único el email address.
Tampoco podría ser el primary key.
Porque el email address podría cambiar perfectamente.
Uy, he puesto aquí esto y esto es así.
Con esto ya hemos creado nuestra primera tabla.
Con la primary key que tiene que ser con unicidad, no nulidad y además inmutabilidad del user id que no va a cambiar nunca.
Con esto, si ahora lo vamos a ejecutar, ya tendríamos nuestra primera tabla.
Si entramos aquí en las tablas, vamos a refrescar.
Fijaos que ahora sí que podemos mirar que aquí tenemos users.
Y hacemos un select rows.
Tenemos usuarios, o sea, la tabla usuarios.
Pero por ahora está vacía.
Para eso vamos a ver cómo meter información en una base de datos MySQL.
Le decimos insert into users.
Y aquí le podemos decir en qué campos queremos meter la información.
Por ejemplo, el user handle, el email address, el first name, el last name, el phone number.
Esta es la información que nosotros le vamos a proporcionar.
Pero el resto, tanto el user id como el created at, no se lo vamos a comentar porque no es necesario.
Ya automáticamente va a ser capaz de decir, ah, bueno, ya el user id lo tengo que autoincrementar y el created at, por defecto, tiene el now.
O sea, le va a poner el timestamp.
Y ahora aquí le pondríamos los valores.
Aquí podéis hacer una cosa.
Podéis ir uno a uno, que no pasaría nada, ¿no?
O sea, podéis poner aquí, por ejemplo, user handle midudep, midudep arroba gmail.com, ¿vale?
First name, Miguel, Ángel.
Y aquí pues tendríamos el número de teléfono, 69999.
Esta sea uno, ¿no?
Esto le podríamos dar enter y esto funcionaría y me estaría introduciendo un solo valor, ¿no?
Lo voy a hacer para que veáis, ¿vale?
Vale, insert into, esto ha funcionado, me ha dicho que check.
Y aquí siempre, no sé si se ve, pero aquí siempre, ¿veis que pone one row affected?
Siempre os va a decir el número de filas que se han visto afectadas.
Ya sea que las estáis borrando, añadiendo, consultando o lo que sea.
Por ejemplo, el show databases, ¿veis?
Aquí lo estamos consultando y como me ha mostrado cuatro bases de datos, pues me ha puesto cuatro rows.
Si seleccionas y te das diez resultados, te va a decir que se han afectado diez.
Si borras cuatro, te va a decir que cuatro.
Esto te da una idea, no siempre real, pero te ayuda a determinar cómo de tocha es tu query.
Porque imagínate que tú haces un select, lo que sea, para atraer información.
Y te dice, ocho millones de rows affected.
Bueno, ahí es cuando te cagas encima.
De hecho, ya os digo una cosa.
Normalmente cuando haces un delete y se te olvida el where,
que hoy en día son más difíciles y luego os explicaré por qué, ¿vale?
Pero cuando haces un delete y se te olvida el where,
y entonces el delete y te dice un millón y medio de filas afectadas.
Y se te ponen los huevos aquí como...
Ahí es cuando tienes el problema, ¿no?
O haces cualquier delete y tú esperas, ¿no?
Esperas que se afecten dos o tres filas y de repente ves ahí que se han afectado miles de filas.
Entonces te cagas encima, pero una cosa...
A mí me ha pasado, me ha pasado, ¿eh?
Se te sube a la garganta y se te escapan y todo, ¿eh?
Ah, fijaos.
Mira, vamos a ver una de las restricciones.
Fijaos que he hecho este insert, ¿no?
Ya le he dado al enter.
Vamos a volver a...
Vamos a darle otra vez.
Ahora me debería petar, ¿vale?
¿Veis que me ha petado?
Me ha petado porque...
Aquí tenemos la respuesta porque me dice,
oye, ha habido un error de que se ha duplicado mi dodef en la key user handle.
Ya veis que hay formas...
Bueno, formas no.
En este caso, cuando insertamos como mi dodef,
le hemos dicho que tenía que ser el handle, tenía que ser único,
y estamos intentando meter otro igual,
pues ya nos dice, oye, esto no puede ser.
No, esto no funciona.
Lo que podéis hacer también si queréis...
Mira, esto lo voy a comentar,
que por si no lo sabéis, para comentar podéis poner guión, guión,
pero me lo voy a pegar para poner más gente, ¿vale?
Voy a añadir más valores.
Y para que veáis que lo podéis hacer más de uno a la vez,
no hace falta que vayáis uno a uno,
podéis hacer algo así, ¿vale?
Lo que podéis hacer...
Bueno, espérate, porque esto lo había hecho yo antes.
En un ejemplo.
Y tengo que mover algunas cositas.
Entonces, podéis hacer un insert de más de una cosa a la vez.
No hay ningún problema, ¿eh?
Que hay veces que la gente dice,
ah, es que hay uno a uno, no.
Lo único que tienes que hacer es separarlo con una coma
y podéis poner tantos como queráis.
De usuarios, el handle lo tenéis aquí,
el email address, first name, el last name, phone number.
Voy a poner uno más.
Bueno, dos más, va.
A ver, uno más.
Vamos, feral.
Vamos a poner un número random, ¿vale?
A ver, otro.
Iván.
Venga, astrack.
Astrack 3.
Pablo me ha dicho que era Hernández.
Pues ahí lo tenéis.
Pero con esto ahora lo tenemos aquí,
le damos al enter y, ¿veis?
Otra vez hemos añadido,
me ha dicho que hemos añadido 5 records.
Ahora en users le damos al enter
y aquí tenemos todos nuestros usuarios
con toda su información.
Un tema importante es cuando una,
como os decía,
una primary key tiene que ser única,
inmutable y no puede ser null.
Por lo tanto,
cuando tenéis una primary key,
este not null ya no es necesario, ¿vale?
Si la pones como primary key,
ya no tiene sentido.
No puedes decirle la restricción de not null
como si lo estuviéramos diciendo dos veces.
Así que ya no es necesario que digáis not null.
En este caso lo podéis quitar,
tampoco pasa nada si lo dejáis.
Vamos a ver cómo podemos tirar una base de datos.
Imagínate que esta tabla, por lo que sea,
no nos gusta por este cambio, ¿no?
Por este not null que no hemos hecho,
por lo que sea.
Hemos dicho, oye,
ahora quiero recrearlo todo de nuevo.
Imagínate que quiero volver a ejecutarlo todo.
Lo quiero ejecutar todo.
¿Qué pasa?
Si yo intento ejecutar todo lo que veis aquí,
voy a quitar el show databases,
que no es interesante.
Claro, quiero crear la base de datos,
quiero usar TwitterDB, no sé qué.
Es como que tiene demasiada información
que no, ¿sabes?
No sirve para...
O sea, se va a duplicar.
Obviamente esto va a dar problemas.
Si le damos aquí,
¿vale?
Fíjate que al intentar ejecutar todo el archivo
y al hacer Create Database,
ya me dice,
oye, al intentar volver a ejecutarlo todo,
la base de datos ya existe.
Esto es un error común, ¿no?
De decir, ah, pero ahora qué hago,
porque no sé qué.
No pasa nada.
Podéis hacer un drop de la base de datos.
Podéis hacer Drop Database
y esto lo que hace es tirar toda la base de datos.
Le podéis preguntar si existe,
porque si es la primera vez que lo ejecutáis
y todavía no existe,
petará.
Podéis hacer esto.
Ahora sabemos que existe,
pero si intentas hacer un drop
de una base de datos que no existe,
te va a decir, oye, que no existe.
Le tienes que decir, oye,
haz un drop de esta base de datos,
si existe.
Y le dices el nombre de la base de datos.
Esto mismo lo podéis hacer
por cada una de las tablas, ¿vale?
Podéis hacer, por ejemplo,
el Create Table esto.
Antes de hacer el Drop Table,
podrías hacer...
O sea, antes de hacer un Create Table,
podrías hacer un Drop Table,
si existe users.
Lo que estamos haciendo es, bueno,
si existe la tabla users,
elimínala antes de crearla.
En este caso,
como hacemos un Drop de Database,
no debería ser necesario.
Para buena práctica,
lo podríamos hacer así.
Y esto lo podríamos volver a repetir
con todas las tablas que queramos hacer.
Ahora, con esto,
si ejecutamos todo el archivo,
ahora puedes ver
que se han ejecutado todas las cosas.
El Drop, el Create, el Use,
el Drop, el Create, el Insert,
se ha ejecutado todo.
Y no importa cuántas veces le demos,
que como lo que estamos haciendo
es limpiarlo todo otra vez,
lo estamos limpiando,
pues ya no teníamos ningún problema.
Hay uno que da un warning,
que es el del Drop Table,
si existe, de users.
Porque no existe antes de crearla.
No existe porque estamos
tirando toda la base de datos.
Entonces, ya hemos creado
la tabla users,
pero obviamente
la tabla users de Twitter
no es suficiente.
Necesitamos tener followers.
¿Qué es Twitter sin followers?
Hacemos el Drop Table,
if exists, de followers,
y vamos a crear la tabla de followers.
Hay diferentes estrategias
muchas veces a la hora
de hacer relaciones
en base de datos.
Todas tienen sus cosas buenas
y sus cosas malas.
Por ejemplo,
según la estrategia que utilicéis,
followers,
y podríamos poner aquí
el follower ID
y el following ID.
Y os voy a explicar
por qué normalmente
se hacen este tipo
de conexiones.
Podemos decir
que sigue al 2, 3,
este sigue al 1
y este sigue al 5.
Y este no se puede seguir
a sí mismo.
Y esto es interesante
porque veremos
un problema con esto
y veremos cómo arreglarlo.
Normalmente,
lo que hacemos
con base de datos
es crear estas relaciones
en las que sabemos
que este usuario de aquí
se refiere,
este usuario se refiere a este,
este usuario 3
se refiere a este,
este 5
se refiere a este,
¿no?
Estamos creando
como relaciones.
¿Por qué hacemos esto?
Porque lo que queremos
normalmente
es asegurarnos
de la integridad
de los datos
y evitar repetir
los datos.
O sea,
aquí tenemos los usuarios
y aquí tenemos
con el ID 5
que sabemos
que es Subnova 6
y aquí,
solo con las IDs,
ya somos capaces
de hacer relaciones
entre la información
que tenemos
en las tablas.
Y ya no necesitamos
volver a recrearlo todo,
ni siquiera necesitamos
aquí dentro de Users
tener un campo
que sea
todos los followers
que tiene
o todos los,
o toda la gente
que está siguiendo.
Lo que podemos hacer
es extraer
esa información
a una tabla intermedia
para hacer estas relaciones.
¿Y por qué hacemos esto?
Porque si no,
las relaciones
dentro de una tabla
serían muy difíciles.
Imagínate,
aquí lo que tendríamos
en Usuarios,
imagínate que yo quisiera tener,
aparte de la ID
y el nombre,
imagínate que quiero tener
todos sus followers.
Sería súper complicado
tener ahí
toda la información
y lo mismo
con toda la gente
que sigue.
Entonces,
lo que estamos haciendo
para asegurarnos
que tenemos los datos
mucho más aplanados
es normalizarlos
en una tabla
donde van a tener
esas relaciones.
Vamos a tener
el Usuario 1
sigue al Usuario 3,
al Usuario 4,
al Usuario 5
y cada una de estas relaciones
va a ser uno de los elementos.
Esto muchas veces
es lo que se le llaman
las relaciones
uno a muchos,
muchos a muchos,
uno a uno,
un usuario,
por ejemplo,
tiene una relación
de que puede seguir a muchos
y un usuario
le puede estar siguiendo
mucha gente también.
Entonces,
este tipo de relaciones
muchas veces
vais a ver
que se pueden separar
en una tabla
y esto te va a ayudar
un montón
a la hora
normalizar los datos,
evitar duplicidad
de datos,
evitar problemas
a la hora
de actualizar los datos,
ser mucho más fácil
a la hora
de extraer los datos.
¿Por qué?
Porque si yo ahora
lo que quiero
directamente es decir,
vale,
quiero traerme
los followers
del usuario
de Elon Musk,
¿vale?
Pues solo tengo que ir
y mirar
aquí cuál es la ID
de Elon Musk
y una vez que tengo
la ID de Elon Musk
digo, vale,
pues traeme
todos los followers
donde el
following ID
sea uno.
Entonces,
pues miraré
todos los que aquí
sea uno,
que aquí en este caso
pues no tendría followers
como se nota
que esta no es la base
de datos que él controla.
Vamos a verlo con código
que lo vamos a ver
mucho más claro.
Vamos a crear
la tabla de followers.
Create table followers.
Vamos a ver
cómo vamos a hacer
las relaciones.
Pues necesitamos
por un lado
el follower ID
que es un entero,
no puede ser null.
El follower ID
va a ser un user ID.
O sea,
va a ser la relación
del user ID.
Así que luego veremos
cómo hacemos esto.
Luego vamos a tener
el follower ID,
o sea,
la persona que sigue,
¿a quién sigue?
Pues following ID
un entero,
no null.
Y ahora,
la primary key,
¿cuál va a ser
la key primaria
que no va a poder cambiar
nunca ese elemento?
Pues la primary key,
como hemos dicho antes,
puede ser más de un campo.
Y en este caso
podemos decir
que la key primaria
es la follower ID
y following ID.
Porque nunca,
nunca va a cambiar eso.
Como ya hemos visto
que el user ID
nunca cambia,
si el usuario 2
está siguiendo
al usuario 3,
esa relación única
única del usuario 2
al usuario 3
se crea
a partir
de las dos IDs.
Porque esas dos IDs
jamás van a cambiar.
Por lo tanto,
la primary key
de la tabla followers
está en esa relación.
Ahora bien,
todavía nos falta algo
y es que le tenemos
que indicar
cómo se relacionan
los datos, ¿no?
Estas flechas
que veis aquí,
cómo le decimos nosotros
a MySQL
que estas flechas
tienen que viajar.
Cómo se relacionan
las dos tablas.
Le tenemos que decir
que hay una relación
entre esta ID
que tenemos aquí
y este follower ID.
De forma que haya
constraints
y ciertas mejoras
y optimizaciones
que ocurran
con estas dos tablas.
Así que vamos a decir
que tenemos
una llave foránea,
¿vale?
Una llave foránea
que es algo similar
a lo que es una primary key
pero un poco diferente
porque no es suya.
Entonces,
¿cuál es la llave foránea
en este caso?
La cadávera foránea
es como un concepto este
para relacionar
la base de datos
y lo que necesitamos decirle
es que nuestra llave foránea key
foreign key
le decimos
oye,
el follower ID
¿a qué referencia?
Esto referencia
a la tabla users
al user ID.
¿Vale?
Y lo mismo le diríamos
con la otra.
Vamos a copiar esto
y le decimos
y que sepas
que también
el follower ID
referencia
a la tabla users
al campo user ID.
Y entonces,
con esto
ya sabes
cuál es la relación
que tiene
entre una y otra.
¿Vale?
Lo cerraríamos aquí
con un punto y coma.
¿Vale?
Ya lo tendríamos.
Hostia,
espérate que aquí se me está quejando.
O igual es que el primary key
tiene que ir abajo del todo.
Sí,
el primary key
tiene que ir abajo del todo.
Hostia,
¿en serio?
Ah,
estoy flipando.
Pues sí,
el primary key
pensaba que no haría falta.
Pero sí,
el primary key
tiene que ir abajo del todo.
Con esto ya crearemos
la tabla de los followers.
Podríamos hacer esto.
La clave foránea,
de nuevo,
un campo
o colección de campos.
También puede ser
una colección de campos
porque,
por ejemplo,
aquí tenemos un primary key
que son dos campos,
por ejemplo.
Entonces estos valores
son requeridos
que coincidan con los valores
de la clave primaria
de otra tabla.
En este caso le decimos
que follower ID
tiene que ser un valor
que referencia
a un user ID
de un usuario.
Esto lo que va a significar
también es que no vamos a crear,
no vamos a poder crear followers
que no existan
dentro de la tabla users.
¿Vale?
O sea,
si yo intento insertar
un follower con la ID 83
y solo hay 60 usuarios,
no me va a dejar.
Me va a decir,
oye,
esto no existe
y lo podemos probar ahora
para que lo veamos.
¿Podría restringir
a nivel de tabla
que follower ID
y follower ID
no coincidiesen?
Muy bien,
eso lo vamos a ver ahora.
¿Por qué?
Mirad,
vamos a ejecutarlo todo,
¿vale?
Para ver si,
¿vale?
Todo se ha ejecutado,
tendríamos aquí en users,
ahora tendríamos followers
y vemos que la tengo vacía.
Vamos a añadir aquí
algunos followers,
si os parece,
insert into followers,
vamos a tener follower ID,
follower ID,
le ponemos valores
y vamos a poner aquí,
ah,
into,
no info.
Vale,
y vamos a poner aquí
alguna relación.
Por ejemplo,
el usuario 1,
que creo que era Midudev,
pues sigue a,
vamos a poner a Ferdinand Alexa,
el 2 sigue a Midudev,
el Marta sigue a Midudev,
Itziar sigue a Midudev,
¿vale?
Pero,
¿qué pasa?
Que Midudev va de listo
y dice,
ah,
pues yo me sigo a mí mismo,
porque me ha sobrado el tío.
Dice,
ah,
pues yo me sigo a mí mismo,
porque la ID 1,
si miramos aquí,
la ID 1,
es Midudev.
Y entonces Midudev dice,
pues me voy a seguir a mí mismo,
pero eso en la lógica del negocio
no tiene sentido,
pero no hemos hecho ningún cambio aquí.
Claro,
esto significa que esto funciona
y que ahora,
si vamos aquí a followers,
podemos ver que Midudev
está siguiendo a Midudev.
Esto no tiene ningún sentido,
así que lo que vamos a hacer aquí
es cambiarlo.
¿Qué podemos hacer?
Creo desde la versión 8 de MySQL,
no me acuerdo si es la 8.1 o punto,
no me acuerdo,
pero de la versión 8
se pueden añadir,
se pueden añadir constraints
para hacer checks,
¿no?
Para que antes de hacer el insert,
porque si no antes
se tenían que hacer con triggers
o en backend
y era un poco rollo,
pero añadieron una forma
de hacer constraints.
Así que te voy a enseñar
cómo puedes modificar una tabla
una vez que la has creado
para no tener que volver a crearla
y además te voy a enseñar
a cómo puedes añadir una constraint,
¿vale?
Como una restricción
a la hora de cómo funcionan los datos.
Por ejemplo,
aquí le diríamos alter table,
vamos a alterar la tabla
de followers
y lo que vamos a hacer
es añadirle una constraint
que le tienes que poner un nombre,
que sea check follower ID,
por ejemplo.
Es importante,
bueno,
tienes que ponerle un nombre
porque las constraints
las puedes quitar,
las puedes listar
y todo esto.
Y esta restricción
le vamos a decir
que tiene que chequear
que el follower ID
sea diferente
o lo puedes hacer así
o así, ¿vale?
Sea diferente
al following ID.
porque así vamos a evitar
que un usuario
se pueda seguir a sí mismo.
¿Qué pasa?
Que si yo ahora intento ejecutar esto,
me va a decir que no funciona.
Me dice,
oye,
es que esta está violada,
esta constraint está violada
porque ya llegamos tarde,
ya lo estamos haciendo demasiado tarde.
Como hemos hecho esto,
ya no me deja hacer este insert,
o sea,
este insert ya me lo deja hacer
pero no puedo hacer una restricción
que justamente violaría
lo que ya hay en la base de datos.
Así que lo que podemos hacer
es moverlo aquí,
¿vale?
Lo vamos a poner justo antes
y ahora cuando lo ejecutemos todo
que va a volver a crear la tabla
y tal,
ahora el pete,
ahora el pete
me lo está dando en el insert
porque ahora el insert me dice,
oye,
es que la constraint,
la restricción que has puesto
de que una persona
no se pueda seguir a sí misma
la estás violando
por culpa de esta.
Vamos a quitarlo,
vamos a hacer,
a ver si esto funciona
y ahora cuando ejecutemos todo,
ahora sí lo tenemos todo en verde
y ahora tenemos la restricción
de que un usuario
no se puede seguir a sí mismo, ¿no?
Ahora que ya tenemos estas tablas,
a ver,
podemos añadir aquí alguna más, ¿no?
Por ejemplo,
¿cuántos usuarios teníamos?
3, 4, 5, 6.
Bueno,
pues podemos hacer
que el 5 siga al 6,
que el 6 siga al 5,
que el 2 siga al 5,
¿vale?
Vamos a,
estamos poniendo como algunos followers
y cosas así.
Lo interesante aquí también
es que si le ponemos
que el 1 sigue al 2
y hacemos aquí el enter,
fíjate que aquí ya estaba siguiendo
y aquí lo he intentado volver a poner
y no me deja,
no me deja
porque como esto es una aquí primaria,
esa relación no puede ocurrir dos veces.
O sea que esto que hemos hecho aquí
del primary key,
esto es interesante también
porque ya nos está haciendo
una restricción
de que no puede ocurrir
la misma operación dos veces, ¿vale?
No puede dos veces seguir
el usuario 1 al usuario 2,
no tendría sentido.
Vamos a ejecutar esto
y aquí vamos a poner los followers.
Ya tenemos aquí
las relaciones de los followers.
Es que aquí ya podéis empezar a,
yo qué sé,
bueno,
recuperar la tabla de followers.
Sería un select follower ID
from followers, ¿no?
Y aquí ya tendríamos
la misma información
que estábamos viendo antes, ¿no?
Y ahora la empezamos a complicar,
que esto es un poco
lo que vimos el otro día, ¿vale?
Aquí tendríamos esto.
Podríamos recuperar
los followers de Midudev, ¿no?
Que follower ID
from followers
where following ID
sea la ID 1,
que es la de Midudev.
Vale, pues ya tendríamos aquí
todos los usuarios
que siguen a Midudev,
que son tres.
Podríamos contar
el número de usuarios
que están siguiendo a Midudev.
Followers count
o followers.
Vamos a ponerle
from followers, ¿vale?
Y esto sería exactamente lo mismo,
pero contando
para tener la cuenta, ¿vale?
Y aquí, pues tenemos
tres followers.
Esto que estáis viendo
ya os podéis imaginar
que son las consultas
que haría la base de datos
para mostrar Twitter.
Imagínate que quieres
hacer la lista,
mira, vamos a complicar,
top tres usuarios
con mayor número
de seguidores, ¿vale?
Para hacer un top tres.
Esto creo que no lo hace Twitter,
pero podría ser.
Vamos a seleccionar
el following ID.
Vamos a contar
el número de follower ID
as followers.
Esto es exactamente
lo mismo que hemos hecho antes.
From followers, ¿vale?
Lo que ahora vamos a agruparlos
de forma que el following ID,
para que no se repitan,
los agrupamos.
Decimos, vale,
quiero saber
el top tres
de todos los usuarios,
a ver cuántos seguidores tienen.
Por lo tanto,
vamos a contar
el follower ID
y vamos a agruparlos
por el following ID.
O sea,
vamos a agrupar
toda la gente
que sigue al ID 1.
Y ahora podríamos poner
limit 3.
Creo que va a salir
seguramente desordenado.
A ver,
¿ves?
Porque pone followers 3,
1, 3.
Lo que podríamos hacer aquí
antes de,
después del group
es un order by
y le decimos
que no lo ordene
por followers
de forma descendiente.
Y con esto
ya deberíamos tener
los que tienen más seguidores.
Por ejemplo,
midudev,
que es el 1,
tiene 3 seguidores,
following ID,
el 5,
no sé quién es,
tiene 3
y el 2 tiene 1.
Como podemos ver,
nos salen los que tienen más seguidores.
Si miramos la tabla aquí de followers,
podemos ver que efectivamente
following ID
hay 3,
estos son 3 midudevs
y del 5 hay 3.
O sea que sí,
que están ahí
correctamente esta información.
Claro,
alguien me dirá,
esto está muy bien,
pero no ves ahí
que sea midudev.
Y aquí es donde está
lo complicado
y lo que hicimos
el otro día
la semana pasada
que si te lo perdiste
y te interesa,
te recomiendo que veas,
en el curso de SQL
desde cero
de la semana pasada
lo que hicimos también
fueron los joins
que lo que te permite
es traerte información
de una tabla
hacia la otra
justamente
gracias
a las foreign keys.
Lo que podemos hacer aquí
basándonos en esto,
vamos a poner
top 3 usuarios
pero haciendo
join.
Vamos a basarnos en esto,
¿vale?
Tenemos aquí
el following ID,
vamos a poner aquí
punto y coma
que si uno no me gusta,
pero vamos a querer
más información,
por ejemplo,
del users,
de la tabla users
vamos a traernos
el user ID
y de la tabla users
vamos a traernos
el user handle,
¿vale?
Vamos a querer
esta información.
Podríamos traernos
también el users
punto first name,
venga.
Entonces,
from followers
queremos la información
de la tabla followers
pero resulta que
de la tabla users
¿dónde lo sacamos?
Tenemos que hacer
un join,
tenemos que hacer
la conexión
entre las dos tablas
y esta conexión
es lo que hemos hecho aquí.
¿Veis esta
estas flechas?
Estos serían los joins.
Lo que estamos diciéndoles
es cómo tienes que traerte
la información,
cómo hacemos este nexo,
este follower ID,
este uno,
¿a quién se refiere?
Pues este uno
vamos a traernos
esta información
y esto será
el users
punto username.
En este caso
lo hemos llamado
user handle,
me parece, ¿no?
O sea,
que así es como
estamos haciendo el nexo
y lo estamos haciendo
con un join.
Oye,
seleccióname
esta información
pero me amplías
la información
gracias a que sabes
que este uno
se refiere
a este uno
y así vas a poder
recuperar
el nombre
de Elon Musk
y ya no solo
sabremos la idea,
también sabremos
el nombre.
Entonces,
para hacer el join
vamos a decir,
oye,
join followers
donde usuarios,
el user ID
sea igual
al followers
followers punto
y aquí le podemos poner
following ID,
¿no?
para saber
quién está siguiendo
a quién
y con esto,
si no me he equivocado
y hacemos así
not unique
tabla alias followers
¿dónde he liado?
¿Puede ser que esto
sea así?
¿Que lo he liado?
Sí.
Es que el join
se hace en users
no en followers
no es porque he puesto
otra vez followers.
El join lo hacemos
en la tabla users
no en la tabla followers
en la tabla followers
es donde estás sacando
ya la información.
Esta sería como
la tabla primaria
entonces de la que
queremos extraer
es de users
así que ahí lo tendríamos
y este sería el resultado.
Lo que hemos hecho
con esto,
fíjate,
en un momento
ya estamos trayéndonos
la información
de dos tablas
tarda nada esta query
evidentemente
no tenemos muchos datos
todavía
pero ya no solo sabemos
el user id
sino que gracias a saber
el user id de la tabla
hemos extraído los datos
también de la tabla
de users
donde ahí sí
tenemos la información
del nombre del usuario
su primer nombre
y todo esto
y podríamos sacar
pues toda la información
que necesitemos
y mucho más
así que ahí tendríamos
un join ya interesante
con solo dos tablas
que tenemos
y ahora vamos a crear
la tabla de tweets
create table
podríamos hacer el drop
otra vez
pero bueno
como ya sabéis hacerlo
lo podéis hacer vosotros mismos
vamos a hacer el drop table
en la tabla de tweets
que tendríamos
un tweet id
también lo mismo
podríamos decir
que sea autoincremental
autoincrement
el user id
¿vale?
que no puede ser
null
y este es súper importante
porque obviamente
todos los tweets
tienen que tener un user id
el texto
del tweet
¿vale?
que esto pues
como son
bueno ahora son más
si tienes premium
pueden ser más
pero se supone
que eran 280
si no me equivoco
¿no?
y no puede ser null
no puedes enviar
un tweet vacío
podemos ponerle
el número de likes
por ejemplo
esto es un entero
que por defecto
empieza en cero
importante ¿no?
que por ejemplo
los números
como número de likes
y tal
tiene sentido
que tenga un valor
por defecto
que es cero
o sea no lo dejéis en null
y lo mismo con
yo que sé
retweets
pues sin default
cero
incluso comentarios
copiamos el created ad
que habíamos hecho aquí
aquí habíamos hecho
cuando se creaba un usuario
created ad
¿no?
timestamp non null
esta línea
pues que
es súper típica
entonces
la vais a poder hacer
cada dos por tres
¿cuándo se creó el tweet?
pues automáticamente
le vamos a poner el timestamp
ahora necesitamos
el foreign key
que va a ser del user id
¿qué usuario ha creado esto?
así que tenemos que referenciar
a la tabla de users
por el user id
y lo mismo
¿cuál es la key primaria?
en este caso
es el tweet id
el tweet id
no puede cambiar
no va a cambiar jamás
lo otro sí que puede cambiar
pero el tweet id
no va a cambiar
así que la key primaria
va a ser la id del tweet
¿por qué es la id primaria?
bueno porque si vais
a cualquier tweet
fijaos
que entráis aquí
y esta id que tenéis aquí
esta sería la id primaria
porque tú no puedes cambiar
esa id
por más que quieras
siempre
se va a referir
a este tweet de aquí
así que ya tendríamos
la tabla de tweets
con esto de aquí
mira tengo por aquí
tengo aquí justo
is insert into the tweets
con el user id
y el tweet text
y aquí tendríamos
la id del usuario
que este se refiere
a midudev
este se refiere
al segundo usuario
¿vale?
o sea importante
mira tengo aquí más
o sea que vamos a poner
más tweets
para tener unos cuantos
fíjate que solo tienes
que poner la id del usuario
¿por qué solo ponemos
dos campos del tweet
cuando hemos creado
aquí un montón?
porque si te fijas bien
la id del tweet
se autoincrementa
o sea que ya se crea
automáticamente
el user id
sí que lo necesita
el tweet text
sí que lo necesita
pero el número de likes
el retweets y comments
por defecto cero
no hace falta
y el created ad
por defecto
es el momento
en el que se crea
así que ya lo tendrías
no hace falta que hagan nada más
vamos a ejecutarlo todo
a ver si lo hemos hecho todo bien
vale aquí me está saliendo
la consulta que hemos hecho antes
de hecho el tema de los selects
es que cada vez que ejecutemos esto
van a aparecer por ahí
creo que también se puede poner
esto así
así que vamos a ver
si esto te gusta
y vamos a comentar los selects
para que no estén saliendo ahí
todo el rato
cada vez que lo ejecutemos todo
y estos también por aquí
pero te los comento
porque luego te paso el fichero
y así los tendrás
lo ejecutamos todo
y al ejecutarlo todo
si vamos por ejemplo
aquí a tweets
y ejecutamos esto
pues ya tenemos aquí
todos los tweets
de cada usuario
ahora
¿qué podemos hacer?
podemos por ejemplo
para complicar esto
podríamos saber
cuántos tweets
ha hecho un usuario
que aquí podríamos complicar
un poco más
y ver cómo utilizar el group
el group
que lo hemos visto antes
pero por ejemplo
cuántos tweets
ha hecho un usuario
a ver
esto sería con un count
o sea que tampoco
porque eso lo podemos mirar
solo
podemos hacer un select
del user id
contarlo todo
aunque puedes contar también
el user id
y contarlo como cuántos ha hecho
esto lo sacamos de tweets
ni siquiera hay que hacer nada más
y lo que podemos hacer
es agruparlos
por user id
entonces
lo que vamos a saber con esto
es cuántos tweets
ha hecho cada usuario
lo que pasa es que
solo vamos a ver ahora
el user id
¿ves?
el usuario 1
ha hecho 5
el usuario 2
ha hecho 2
el usuario 3
ha hecho 2
esto que también puede parecer una tontería
pero algo como esto
a ver
os voy a decir algo
algo como esto
o sea por ejemplo
cuando veis esto
de 200 seguidores
o veis aquí que pone
12,4 mil tweets
claro
alguien puede pensar
hostia
twitter lo que está haciendo
es cada vez que necesita
esa información
está haciendo algo como esto
¿no?
donde dice
where user id
es 1
que es el midudev
¿no?
ostras
pues tiene 5
vale
pues va a enseñar aquí un 5
esto no funciona así
¿vale?
esto no es lo que hace twitter
exactamente
porque si tuviese que hacer esto
el coste que tendría la API
sería muy bestia
¿no?
hay diferentes formas
¿no?
una podría ser cachearlo
decir
oye
esta consulta
la voy a cachear
4 horas
si que la hago
pero la cacheo
vale
eso puede tener sentido
pero hay veces
que lo vamos a ver ahora
que se puede hacer de otras formas
¿vale?
que se puede hacer con un trigger
que lo
ahora lo veremos
haremos los updates
y luego te enseño
como son los triggers
pero para que tengas un poco
la idea de que no se hace exactamente así
mira
vamos a hacer una subconsulta
porque muchas veces
me la habéis preguntado
¿no?
por ejemplo
para obtener los tweets
de los usuarios
que tienen más de 2 seguidores
¿qué es una subconsulta?
porque en twitter
me la preguntamos de una persona
¿vas a hacer subconsultas?
a ver
las subconsultas
es lo más fácil del mundo
a veces
es una alternativa
a hacer joins
o al hacer
dos consultas
de forma secuencial
y una subconsulta
básicamente
una consulta
dentro de otra consulta
aquí queremos obtener
los tweets
de los usuarios
que tienen
más de 2 seguidores
si ya sabemos aquí
sabemos que por ejemplo
el usuario 1
tiene 5
el usuario 2
tiene 2
el usuario 3
tiene 2
vale
imagínate que queremos
de los que tienen más de
ah no
estos son
de tweets
bueno
que han hecho tweets
a ver tweets
mira aquí tenemos
lo de tweets
y tenemos
el usuario 1
que ha hecho 3
4
5
y el usuario 2
ha hecho 2
y el usuario 3
ha hecho 2 también
vamos a hacer
que todos los usuarios
que tengan más de 2
entonces solo nos deberían
aparecer los tweets
del 1
¿no?
de mi dudé
pero claro
a lo mejor no lo sabemos
sino que simplemente
son
no sé
lo queremos ver
y ya está
obtener los tweets
de esta gente
vamos a obtener
el tweet
tweet id
a ver los tweets
tenemos el tweet id
tweet text
vale
tweet text
y el user id
y esto lo vamos a sacar
de los tweets
y aquí le decimos
donde el usuario
esté dentro
y aquí
podemos hacerle a su consulta
¿qué es lo que estamos
haciendo aquí?
lo que estamos diciendo es
oye recupérame
la id del tweet
el texto del tweet
y el id del usuario
de la tabla tweets
de todos aquellos usuarios
que estén dentro
de esta consulta
y aquí podemos hacer
la consulta
de seleccionar
donde el following id
vamos a mirar
que tenga
más de dos seguidores
entonces miramos
que el following id
de followers
lo agrupamos
esto lo habíamos hecho
antes
con el following id
following id
donde la cuenta
sea mayor
a dos
donde count
sea
a ver si la he liado
ah
no
no es con el where
claro
si lo estamos agrupando
esto es
ah
dios mío
vaya fallo
cuando agrupas
es que no es el where
cuando agrupamos
el where
del group
es el having
lo que es
selecciona
vamos a seleccionar
el following id
de followers
los agrupamos
por el following id
y lo que tenemos
es que la cuenta
de los que agrupamos
sea mayor a dos
el where
en todo caso
va arriba
va arriba
y claro
no sería para
la agrupación
que estamos haciendo
ahora lo vamos
vamos a ver la diferencia
para que veáis
porque me ha volado
la cabeza esto
pero lo que estamos
haciendo con esto
mira lo vamos a poner aquí
vale
ah no
este no hace falta
que tenga esto
vamos a ponerlo aquí
vale
aquí tendríamos
vamos a quitar
el having primero
vale
mira
aquí primero tendríamos
todos los following id
de followers
que se agrupen
por following id
no debería ser
agruparlo por follower id
un momento
vamos a seleccionarlo tonto
from followers
tenemos select
follower id
a ver como había puesto esto
como lo había puesto esto
select following id
following id
vale
gente que sigue
desde followers
y lo habíamos agrupado
a ver como lo había agrupado
by following id
o sea selecciona
el following id
group
by
following id
vale
tiene sentido
o sea
esa es la persona que sigue
con el nombre es un poco raro
pero esta es la persona
que inicia
el seguimiento
y esta es la persona
de destino
a la que está siguiendo
tiene sentido
lo que estamos haciendo
seleccionar
el following id
from followers
y lo agrupamos
por following id
o sea esto es para saber
por ejemplo
cuantos usuarios
están siguiendo
a este de aquí
al following id
y cuando lo agrupamos aquí
para saber
claro cuando hacemos esto
ahora mismo
lo que estamos es agrupando
todos los que tienen seguidores
y aquí en following id
este tiene seguidores
este tiene seguidores
este tiene seguidores
pero no sabemos
los que tienen
más de dos seguidores
para eso le decimos
que los que estamos agrupando
o podríamos poner aquí
mira
count
si lo hacemos así
vale
ya sabemos los seguidores
que tiene cada uno
el uno tiene tres seguidores
as followers
vale
ponemos este nombre
el uno tiene tres seguidores
el dos tiene un seguidor
el cinco tiene tres seguidores
el seis
tiene un seguidor
y ahora le decimos
vale
pero yo lo que quiero
es que me filtres
los que tienen de seguidores
mayor que dos
por ejemplo
y así lo tendríamos
de que tengan mayor que dos
y ahora sí
tenemos todos los que tienen
más de dos seguidores
entonces
si esto
el having
claro que lo tiene
postgresql
lo tiene
mysql
postgresql
y todo esto
el having
sería una forma
de filtrar
no con el where
sino que estamos filtrando
la agrupación
con esto ahora
que ya tendríamos
los followers
que tiene cada uno
lo que podríamos tener aquí
los que tienen
más de dos
ya podríamos
meter esto aquí
esto nos devolvería
el following id
lo malo es
que como lo que queremos
es que nos devuelva
solo y justamente
las ideas de usuario
para utilizarlo
como una subconsulta
este count
que hemos hecho aquí
lo podemos mover aquí
y no hacer el select
porque necesitamos
que esto
nos devuelva
solo
las ideas
de los usuarios
como solo queremos
estas ideas
cuando hagamos
el user id
in
lo que queremos
es justamente esto
y ahora
tendríamos los tweets
de solo aquellos usuarios
que tengan
más de dos
y ya está
pues esto sería
por ejemplo
una subconsulta
muy bien
venga
sigamos
vamos a ver
cómo usar mysql
lo veremos
hoy no
hoy no
porque hoy la idea
era pues
meterse con esto
y ya está
mira
vamos a ver
para que veamos
todos los temas
por ejemplo
los delete
si queremos eliminar
un tweet
por id
por usuario
podríamos eliminarlo
mira delete
si queréis eliminar
un elemento
de tweets
eliminamos
donde
que no se os olvide
aunque mira
una cosa
este es uno de los
errores típicos
el delete from tweets
aunque esto es un error
que mucha gente dice
que comete
lo cierto
es que no
no suele ser tan fácil
mira
veis que no me ha funcionado
mira
aquí ves
me ha puesto un rojo
delete from tweets
y me dice
estás utilizando
save update mode
y has intentado
hacer un update
de una tabla
sin poner un where
desde hace un tiempo
se puede utilizar esto
como un save mode
en el que
de alguna forma
si ve que haces
un delete
sin el where
te avisa
vale
a ver
podéis ir a saco
en empresas serias
esto no se puede hacer
hay modos
de sql
en el que ya no puedes hacer esto
tenéis el save sql mode
lo podéis quitar
de hecho
podéis
y de hecho también
incluso hay formas
de tirar para atrás
lo que acabáis de hacer
pero
lo que podéis hacer
para
para si
si queréis ir a saco
y decir
no es que esto
podéis
cambiar el set
sql
save updates
lo ponéis a cero
y ahora sí que funcionaría
vale
ahora sí que diría
ah vale
perfecto
mira lo vamos a hacer
vale veis
delete from tweets
no
no
ahora los ha borrado
pero fíjate que tienes que forzarlo
normalmente
en base de datos
hoy en día
ya no hacéis el delete from
se os olvida el where
y a tomar por saco
vale
lo digo para que lo sepáis
porque el meme está muy gracioso
pero
hoy en día
ya hay muchas empresas
que tienen muchos de
muchos de
de este tipo de checks
vale
para que no valguéis
podéis eliminar por
la idea del tweet
por ejemplo del 1
esto
pues lo podéis hacer
y funciona
podéis hacer también
delete
ah espérate
que es que esto
tenemos que ejecutarlo
todo
vale
vale
ahora sí
también podríamos
hacer el delete
de tweets
lo podéis hacer
por user ID
vale
para eliminar los tweets
del mitodev
podéis incluso también
borrar
lo que pasa es que este
puede ser que no funcione
vamos a ver
podéis borrar incluso por texto
decir mira
todos los que
ponen
Elon Musk
eliminar todos los que ponen
el texto de
tweets where
tweet
text
like
Elon Musk
o sea todos los que hablen
de Elon Musk
mira aquí hay uno que habla
de Elon Musk
se supone que debería
borrar uno
debería borrar uno
¿veis?
y ha borrado uno
y ahora ese que ha hablado
de Elon Musk
pues ya no lo borra
esto debe ser algo parecido
a lo que hace Twitter
para
para
para joderte
el algoritmo
y cosas así ¿no?
que detecta textos
y cosas
esto sería un poco
los deletes
y podéis hacer los where
que haríais con los selects
lo mismo podéis hacer
con el update
a la hora de actualizar
el número de comentarios
de un tweet ¿no?
que habíamos visto antes
que teníamos aquí en tweets
select
all from tweets
¿vale?
teníamos aquí por ejemplo
el número de comentarios
y esto es importante
lo que vamos a hacer ahora
porque ahora cuando veamos
los triggers
esto es una cosa
que vamos a hacer
¿no?
quiero actualizar tweets
y setear
que el número de comentarios
sea igual al número
de comentarios
más uno
podéis hacer esto ¿vale?
no hace falta que pongáis
esto
sino que hay veces
que podéis hacer
utilizar el mismo valor
y hacer más uno
de hecho esto puede ser
una buena práctica
porque así siempre
esto es como los set state
de react
si has hecho react
así se va a asegurar
que utiliza el último valor
y no el valor
que le estás pasando
por backend
y cosas así
y esto lo podéis hacer
con el tweet
que queráis
o sea que lo mismo
tendríamos la actualización
lo que queremos setear
y además podéis hacer
una operación
utilizar el mismo campo
que queréis actualizar
le ponéis el where
y así os aseguráis
que solo el tweet
con la id esta
pues se va a actualizar
y ahora
hostia
ah claro
porque lo hemos borrado
hemos borrado este
o sea que no lo ha encontrado
vale ahora sí
ahora deberíamos ver
que el tweet 2
ves
tiene el comentario
en 1
y esto pues lo podríamos
llevar
no sé
a reemplazar
reemplazar
reemplazar texto
también lo podrías hacer
vale
actualizar de tweets
y setear el tweet text
y podéis utilizar funciones
por ejemplo
reemplazar texto
reemplazamos
el tweet text
y le decís
que donde ponga
a ver
me encanta
entrando twitter
mira twitter
donde ponga twitter
porque no sé si lo sabéis
que van a sacar
un nuevo twitter
vamos a poner threads
así reutilizamos
todos nuestros tweets
y le podemos poner
el where
tweet text
sea like
y tenga
twitter
allí donde veamos
que existe
la palabra twitter
reemplazamos
el twitter
por threads
entonces así evitamos
que intenta
actualizarlos todos
o actualizar
donde realmente
lo necesita
vamos a ver
si este ha funcionado
vale
y ahora mirando aquí
pues ahora vemos
threads
ha hecho un reemplazo
del texto
para el que no sepa
que es esto de threads
es la nueva red social
que va a sacar meta
que parece ser
que la va a sacar
mañana mismo
y que la idea
es que va a ser
una copia de twitter
o sea es un twitter killer
es un twitter killer
le tengo bastante curiosidad
la verdad
le tengo bastante curiosidad
yo me voy a abrir
una cuenta
los sabidios
no saldrá en Europa
por protección de datos
no lo puedo creer
no lo puedo creer
si eso es verdad
mal pinta la cosa
mal pinta la cosa
porque significa
que muchos datos
nos van a quitar
bueno
ya hemos visto
delete
update
create table
hemos visto un montón
como serían los likes
a ver
aunque yo he creado aquí
claro
fijaos
aunque yo en los tweets
tenemos el número de likes
no tenemos
quien ha hecho like
si tu entras a un tweet
bueno no se si se le puede
si le das aquí al me gusta
puedes ver
quien le ha dado like
puedes ver
quien le ha dado like
entonces hay una relación
ahí
no solo del número de likes
sino también una relación
de quien ha hecho
esos likes
y es super interesante
y aquí es donde se ve
justamente el poder
de mysql
en el que tienes que
seguir creando tablas
para crear estas relaciones
esto no es sql
seguramente salía de otra forma
porque ya sabéis
que funcionan con colecciones
y documentos
pero aquí
vamos a tener que hacer otra vez
como una tabla
para una relación
donde vamos a tener
por un lado
el quien ha hecho
el
claro
el user id
sería la persona
que ha hecho el like
vamos a tener el tweet id
que sería
el tweet
que le gusta
luego tendríamos
podríamos decir
cuando lo ha hecho
no sé si es importante
cuando ha hecho el like
yo creo que no es importante
yo creo que no es importante
así que vamos a poner
foreign key
donde tenemos el user id
que esto referencia
a users
user id
vale
tenemos el foreign key
donde tenemos
el tweet id
que esto referencia
a los tweets
el tweet id
y teníamos el primary key
que de nuevo
es que el user id
y el tweet id
porque esta relación
solo puede ocurrir una vez
o sea
no hay
joder
siempre se me olvida esto
un usuario
no le puede gustar
el mismo tweet
dos veces
por lo tanto
la llave primaria
y única
irrepetible
e inmutable
es la relación
de que al user id
le guste exactamente
ese tweet id
y no le puede gustar
dos veces
eso
tiene que ser único
esta sería la tabla de tweets
y ahora ya podríamos empezar
a poner pues algunas
de estas relaciones
lo mismo
tweet likes
lo que hemos hecho antes
le tenemos que pasar
el user id
el tweet id
y aquí
que valores ponemos
bueno aquí vamos a inventar
al usuario
al midudev
le gusta el tweet
tres
al midudev
le gusta el tweet
seis
al no se quien
le gusta el siete
bueno no se cuantos tweets
hemos hecho
vale el siete
si que existe
el siete
vale tres
el cuatro
el siete
uno
el siete
aquí no hace falta
que hagamos una restricción
de que a un usuario
no le pueda dar like
a su propio tweet
porque eso es una cosa
que sí que es correcta
pero bueno
para que más o menos
os hagáis una idea
a ver vamos a poner
algunos más
tres seis
dos siete
tres siete
cinco siete
vale vamos a poner
unas relaciones
de unos cuantos likes
vamos a ejecutarlo todo
para no se nos escape
vale
no puede
constrain
alguna cosa ha hecho mal
referencia tweets
tweet id
ah es que el seis este
me parece que el seis
lo hemos eliminado
en algún momento
por algo
puede ser
o sea es que estoy
referenciando a alguno
que no existe
no sé exactamente cuál
vamos a ver
este
este sí que exista
uno cuatro
a ver si esto le gusta
uno cuatro
o sea que el cuatro
el cuatro no existe
dos tres
vale
dos tres sí que existe
vale
o sea que es el cuatro
que el tweet id cuatro
en algún momento
a lo mejor ahí
hemos puesto unos deletes
y tal
a lo mejor
claro
voy a quitar los deletes
porque ves que aquí
user id
lo estoy borrando
y seguramente
por eso desaparece
los voy a comentar
y así no desaparecen
y ahora sea más fácil
que hagamos las relaciones
cuatro
el dos le gusta el uno
el tres le gusta el uno
al cinco
le gusta el dos
y le gusta el tres
vale
vamos a hacer ahí
unas cuantas relaciones
lo ponemos
lo recitamos todo
y ahora sí
si ponemos aquí
tweet likes
deberíamos tener
como las relaciones
de likes
vamos a hacer
algunas consultas
por ejemplo
hacemos una
y así
y ya vamos a los triggers
porque los triggers
es algo súper interesante
y os dejo aquí
es que aquí
os podéis preocupar
de hacer los joins
que hemos hecho antes
para sacar la información
y tal
por ejemplo
yo que sé
vamos a obtener
este es muy típico
vamos a hacer este
que sea
obtener el número
de likes
por tweet
porque ese sí que es importante
y este es bastante fácil
obtener el número
de likes
para cada tweet
este es bastante importante
y os dejo para vosotros
para que hagáis el join
que es un momento
mira
habría que seleccionar
el tweet id
tendríamos que contar
bueno voy a poner todo
como like count
todas las veces
que salga el tweet id
en esta tabla
significa que es un like
y tenemos que contar
cada vez que aparezca
y esto lo tenemos que hacer
del tweet likes
y lo que único que tenemos que hacer
es agruparlos
por el tweet id
y ya está
o sea
esto sería para tener
el número de likes
de cada uno de los tweets
¿ves?
y aquí tendríamos
que el tweet id 1
tiene 3 likes
no sabemos que los ha hecho
eso lo podremos recuperar también
pero lo importante
es que ya tenemos
cada uno de
el número de likes
que tener cada tweet
y esto como lo hemos hecho
pues gracias al group by
lo que hace el group by
es que cada vez
que se repite
¿no?
lo que estamos haciendo
es este tweet id
¿cuántas veces sale?
1, 2, 3
pues lo vamos a aplanar
lo vamos a agrupar
y además
en el otro campo
estamos poniendo
cuántas veces ha ocurrido
¿no?
hacemos el count
y así es como
lo estamos agrupando
¿no?
agrupamos cuántas veces
se repite esto
3
lo dejamos en una sola fila
los agrupamos
y al su lado
en otra columna
le decimos el número de veces
que había aparecido
esto es
súper típico
súper típico
vamos a ver los triggers
esto es un tema
más avanzado
pero yo creo que es súper interesante
¿qué son los triggers?
a ver
triggers
triggers
bueno no sé si habéis visto esto
de triggers
¿qué es un trigger?
pero esto es lo que pasa muchas veces
en trigger meme
esto es lo que pasa muchas veces
en Twitter
que dices algo
y la gente le pasa
algo como esto
estos son triggers
básicamente
cuando dices algo
y de repente
se le ponen caras así
de
a ver si buscamos
los gifs
mira
el que me gusta
es este
este está chelísimo
este está chelísimo
hostia
que te partes
trigger
trigger
bueno pues
la verdad
es que es exactamente esto
lo que es un trigger
literalmente
¿qué es un trigger?
un trigger es
que cuando ocurra algo
en nuestra base de datos
por ejemplo
cuando antes o después
de actualizar
o insertar
lo que vamos a querer
es hacer algo
fijaos
en nuestras tablas
que teníamos
usuarios
teníamos usuarios
en usuarios
una cosa hubiera estado chula aquí
es tener
por ejemplo
un follower count
¿no?
y que esto sea un integer
que no sea null
y que por defecto
sea cero
¿ok?
esto podría ser interesante
que todos los usuarios
tengan una cuenta
de followers
porque no tiene sentido
que cada vez
que queramos ver
cuántos usuarios
están siguiendo
o sea cuántos followers
tiene un usuario
tengamos que hacer
una query
con un join
que no sé qué
porque eso va a hacer
que vaya mucho más lenta
la base de datos
así que hay veces
que puede ser interesante
que tengamos calculados
ciertos campos
o ciertas consultas
antes de tener que
volver a mirarlas
continuamente
¿qué pasa?
a un usuario
lo pueden seguir
a lo mejor
yo que sé
mil personas al día
pero no es algo
que vaya a ocurrir
que de repente
vayan a seguirle
100 millones de usuarios
en un día
no tiene sentido
¿no?
normalmente las escrituras
de cuánta gente
te sigue
suele ser bastante poca
bastante escalonada
y tal
así que lo que puedes hacer
es esto
es decir
vamos a pensar
cada vez
que se inserta
un follower
en la tabla followers
porque nosotros
tenemos ya la tabla followers
la tenemos aquí
¿vale?
tenemos esta tabla followers
donde tenemos la relación
de quién sigue a quién
pues en lugar
de tener que hacer
esto de
vamos a ver cuántos followers
¿ves?
cuántos followers
tiene mi dude
pues en lugar
de hacer este select
que igual es muy costoso
y que esa tabla
cada vez va a ser más grande
lo que vamos a hacer
es decir
mira
vamos a crear un trigger
que le vamos a llamar
increase follower count
y lo que hacemos
es que esto
debe ocurrir
después de hacer
una inserción
en la tabla followers
esto lo que se le dice
es en qué momento
debe ocurrir
después o antes
de qué acción
y en qué tabla
tenemos que mirar
o sea que
después de insertarse
en la tabla followers
aquí le podemos decir
para cada
para cada fila
o le podemos indicar
para filas en concreto
y tal
pero en este caso
para cada fila
vamos a decirle
que lo que tenemos
que empezar es
y aquí le decimos
cómo queremos actualizar
nuestra base de datos
o si queremos hacer
un delete
un update
podemos hacer lo que queramos
en este caso
lo que queremos
mira
vamos a poner aquí
el end
¿vale?
y ahora te explicaré
una cosa
que es bastante
polémica
que no me gusta mucho
de MySQL
pero al menos aquí
lo que necesitamos es
aquí decir
vale
cuando se hace un insert
de un nuevo follower
en la tabla followers
lo que voy a querer
es decir
vale
pues en usuarios
vamos a actualizarlo
y vamos a decirle
que el follower count
sea igual al follower count
más uno
¿vale?
vamos a incrementar en uno
su número de usuarios
y lo que tenemos que asegurarnos
es que estamos actualizando
el usuario correcto
o sea que el user id
tiene que ser igual
y aquí utilizamos
una palabra clave
que tiene MySQL
que aquí se llama new
donde se refiere
al nuevo
a lo que estamos añadiendo
en esta línea
¿no?
lo que estamos añadiendo aquí
y ahora veremos
un ejemplo
¿vale?
o sea
after insert on followers
o sea cuando tú hagas un insert
follower
no sé qué
no sé cuánto
ese objeto
que estamos insertando
es este que tenemos aquí
en new
y por lo tanto
podemos acceder
por ejemplo
al following id
de ese elemento
que estamos añadiendo
que estamos haciendo el insert
lo podemos capturar aquí
y decimos
vale
hazme un update
de users
le incrementamos en uno
y nos aseguramos
de que
el contador
que estamos incrementando
es el del usuario
que ahora está siguiendo
y esto es lo que haríamos aquí
ahora
aquí viene un poco
lo polémico
que ¿qué pasa?
que las sentencias
para terminarlas
en MySQL
bueno en SQL
en general
se hace con punto y coma
como podéis ver aquí
¿no?
se hace con un punto y coma
pero ¿cuál es el problema
del punto y coma?
creo que he puesto bien el trigger
¿no?
que es que este se me queja
statement is incomplete
update user
¿he hecho algo mal?
bueno
si no ahora miro
lo del delimiter
que seguramente es esto
el tema es
que para terminar una sentencia
en SQL
se termina con el punto y coma
pero ¿qué pasa?
que no podemos utilizar
el punto y coma
también en el trigger
porque si no
no sabe
cuando está terminando esta
o cuando está terminando el trigger
así que lo que tienes que hacer aquí
es indicarle
cómo quieres delimitar
y lo puedes hacer
con el formato
que tú quieras
así que le tienes que cambiar
el delimitador
de SQL en este momento
y le puedes poner
lo que tú quieras
le puedes poner
bueno esto no tiene mucho sentido
podrías poner esto
¿vale?
entonces le decimos
vale
delimítame
utilizando esto
así que ahora aquí
en este end
le podemos decir
que aquí es donde va a terminar
y ahora volvemos a tener
el de siempre
es el punto y coma
así nos aseguramos
que delimitamos
correctamente el trigger
que podemos utilizar aquí
la sentencia
con el punto y coma
y así lo va a entender
perfectamente
y lo bueno de esto
es que ahora
cuando nosotros hagamos
un insert
en la tabla followers
automáticamente
se va a actualizar
la tabla users
y se va a incrementar
el número de usuarios
que se están siguiendo
de hecho
teníamos por aquí
inserts de followers
si no me equivoco
aquí ¿no?
que tenemos unos cuantos followers
esto lo vamos a mover
aquí
a ver si funciona
nuestro trigger
que no lo hemos liado
lo vamos a mover aquí
lo vamos a hacer
después del trigger
¿vale?
fíjate que tiene nombre
porque los triggers
los puedes eliminar
los puedes hacer un drop
o sea de hecho
podemos drop trigger
if exist
increase
follower count
y así te aseguras
que si ya existe
lo eliminamos
lo creamos
after insert
no sé qué
no sé cuánto
y luego hacemos el insert
¿no?
insert followers
aquí estamos haciendo
insertando followers
por ejemplo
el 1 sigue al 2
aquí el 2 sigue al 1
el 3 sigue al 1
o sea que aquí el 1
debería tener el num count
a 3
vamos a ejecutar todo esto
¿vale?
y
you can round
this command now
hostia
drop trigger
if exist
dice que no
ah
es que lo he puesto aquí
en medio
es que esto
en todo caso
debería ser aquí
es que lo he puesto
justo después del trigger
del delimiter
y esto no
no tiene sentido
¿vale?
entonces
ponemos ahora así
you're using
where the use key
¿vale?
el update tweets
users
follow count
a ver dice
estás
ah
se está quejando
del replace
ahora
replace
de un update
que habíamos hecho aquí
bueno
esto lo vamos a quitar por ahora
no sé por qué ahora se me queja de eso
vale
vale
hemos hecho los inserts
estos inserts
y ahora si miramos los usuarios
from users
¿vale?
aquí podemos ver
que el follower count
se ha actualizado automáticamente
o sea
este
es la tabla users
y lo que ha pasado es que
cada vez que hemos insertado
aquí al final
un follower
en la tabla followers
se ha disparado
el trigger
y ha dicho
vale
después de insertar
en followers
para cada uno
de los que has insertado
o sea
para este
para este
para este
para este
cada vez que has insertado uno
lo que hemos hecho
es actualizar
la tabla users
porque muchas veces
la gente
se cree que esto se hace en backend
y no se hace en backend
no se hace en backend
no o sea
tiene mucho peligro
esto muchas veces
lo que tiene sentido
es hacerlo
exactamente aquí
en la base de datos
porque lo que hacemos
en la base de datos
es asegurarnos
que está ocurriendo
cuando tiene sentido
vale
y no que se pueda cortar
o lo que pase
cosas buenas y malas
cosas buenas
la normalización
la asegurarte
de que se actualizan las cosas
cosas malas
esto tiene
un problema de rendimiento
en el que tienes que tener cuidado
el número de triggers
que haces
cuanto más grande
es la base de datos
y más triggers
disparas
cada vez que actualizas algo
pues más tiempo
puede tardar
en terminar
puede ser un poco peligroso
también
puede haber una race condition
imagínate
un trigger
no te va a asegurar
que ha terminado
exactamente
cuando a lo mejor
haces un select
desde otro sitio
sí que no vas a tener problemas
a la hora de actualizarlo
porque sí que lo bloquea
pero puede ser
que tengas algún momento
en el que la información
no sea exactamente
la misma que esperas
así que es otra cosa
si tienes muchos triggers
especialmente eso puede ser
problemático
así que es un tema
que lo tienes que tener
con cuidado
vale
lo tienes que tener con cuidado
porque muchas veces
si no
lo que puede ser
es que te tire la base
de datos
que puedes hacer
cosas alternativas
que puedes hacer
el trigger puede estar bien
para cosas que sí o sí
quieres normalizar
pero hay veces
que a lo mejor
esto puede ser
un proceso
en el background
que vaya actualizando
cada x tiempo
o que vaya acumulando
que diga
ostras
le han seguido
10 personas
pues cuando le siguen
10 personas
actualizamos el contador
vale
no lo vamos a actualizar
cada vez que le sigue
una persona
¿por qué?
porque todo lo que puedas
diferir en carga
pues mejor
y puedes hacer
este tipo de cosas
el hecho de ir
acumulando
como en una pila
y que digas
bueno
pues ya está
porque imagínate
si esto funcionase
exactamente así
vale
lo que podrías hacer
es reventarlo
también este trigger
tened en cuenta
que ahora
está incompleto
porque si ahora
alguien deja
de seguir a la persona
lo que estaríamos
es incrementando
continuamente
el número
de usuarios
así que
esto mismo
lo tendríamos que hacer
también
para cuando se elimina
que se pueda hacer
o sea
podríamos hacer
create trigger
increase
en lugar de increase
decrease
decrease
after
en lugar de insert
sería delete
¿no?
cuando hacemos el delete
para cada una
y en lugar de un más
sería un menos
entonces ahora
cada vez que se elimina
cada vez que dejamos
de seguir a alguien
ahora lo que hacemos
es asegurarnos
que estamos
decrementando
el número
¿vale?
así que así como
lo tendríamos
correctamente
y estos serían
ya los
serían los
triggers
lo cual está
bastante bien
hombre al final
hemos visto
cómo crear
una base de datos
muy parecida
a lo que sería
twitter
que le faltaría
mucho obviamente
por ejemplo
deberíamos hacer
lo mismo con
retweets
con charlas
comentarios
y tal
pero que es una
base
en lo que se podría
llegar a hacer
pues un clon
de twitter
con todo esto
y además hemos visto
cómo hacer selects
selects algo
complicados
con joins
con groups
con having
hemos visto
cómo actualizar
cómo borrar
cómo dropear
tablas
cómo alterar
tablas
cómo hacer
constraints
cómo hacer
triggers
o sea
no está mal
en lo que viene
un semestre
lo vimos acá
¿has visto?
no ha estado mal
en menos de dos horas
no ha estado
nada mal
dice
depende de cómo
fiable necesites
el dato
puedes tener una
tarea programada
eso lo que hemos
comentado
hace un momento
sí efectivamente
más que fiable
es como de fresco
necesitas que sea
el dato
por ejemplo
en un banco
seguramente es súper
importante
que tu cuenta corriente
el número de dinero
que tienes
sea algo que sea
casi en tiempo real
en cambio
el número de seguidores
de twitter
pues no hace falta
que sea en tiempo real
seguro que os ha pasado
tanto cuando veáis
un vídeo de youtube
vistas y cosas así
os habéis dado cuenta
de que las vistas
los likes y tal
se actualizan cada mucho
entonces
uff
no está mal
he ido haciendo
un speedrun
de la universidad
sí sí
no está mal
dice
joder
dice
me gustaría que ahora
te asegures la seguridad
coño
vamos a calmarnos
le hemos dado cañita
y