Subo cambios de los ultimos dias del curso

00.Temas.md

@@ -22,10 +22,22 @@
 
 - Querys Avanzados.
     - Uso de JOIN y diferencias con los operadores de conjuntos
-    
+    - INNER JOIN
+    - LEFT JOIN
+    - RIGHT JOIN
+    - FULL OUTER JOIN
+
 - Transacciones.
+
 - Triggers. 
+
 - Procedimientos almacenados.
+
 - Funciones.
+
 - Optimización.
+    - Vistas
+    - Indices
+    - Rendimiento
+    
 - Técnicas avanzadas.

conjuntos/conjuntos.md

@@ -0,0 +1,103 @@
+# Operadores de conjuntos
+
+En sql se pueden tomar dos conjuntos de datos y hacer operaciones de conjuntos como union, interseccion o resta, para ello se utiliza loq ue se conoce como operadores de conjunto y existen varios de ellos. Haremos una revision general.
+
+![](assets/20220105_030256_1.png)
+
+## UNION y UNION ALL
+
+Esete operador permite unir o sumar dos conjuntos de datos.
+
+*Sintaxis*
+
+```
+SELECT campo from tabla
+UNION
+SELECT otrocampo from otratabla
+```
+
+Esta unión se puede hacer de dos tablas diferentes, con  la única condición de que el número de campos y tipos de datos  sean compatibles entre un SELECT y el otro.
+
+![](assets/20220116_173701_Circle1.png)
+
+En las operaciones de conjuntos equivale, el ejemplo  anterior equivale a
+A ∪ B.
+
+### Implementación
+
+*Sintaxis*
+
+```
+select id from categorias c 
+union
+select id from productos p 
+```
+
+
+![](assets/20220116_173735_word-image-416.png)
+
+Además, se puede hacer una diferenciación entre UNION y  un UNION ALL permitiendo o no duplicados que además influye en el tiempo o número de registros que regresa cada uno de ellos, pero en general se trata de la unión de conjuntos.
+
+## INTERSECT
+
+Toma dos consultas de entrada (mismo número de campos y tipos de datos compatibles) y genera una salida con los  registros que están en ambas entradas.
+
+En las operaciones de conjuntos tradicionales, la intersección de A y B se denota como A ∩ B y se codifica en términos generales como.
+
+
+![](assets/20220116_174156_word-image-419.png)
+
+*Sintaxis*
+
+```
+SELECT campo from tabla
+INTERSECT
+SELECT otrocampo from otratabla
+```
+
+En mysql no se encuentra la instruccion except en algunos otros dbms se utiliza minus en mysql se suele usar para esta tarea NOT IN, NOT EXIST o inluso con un LEFT OUTER JOIN
+
+*Sintaxis*
+
+```
+SELECT campo from tabla
+WHERE campo IN 
+(SELECT otrocampo from otratabla)
+```
+
+### Implementación
+
+*Sintaxis*
+
+```
+select id from tabla1
+where id in (select id from tabla2)
+```
+
+
+# EXCEPT
+
+Toma dos consultas y genera una salida con los registros que se encuentren en la primera pero que no se encuentren en la segunda.
+
+Si UNION equivale a una suma de conjuntos, EXCEPT equivaldría a una resta en terminos generales se escribe como.
+
+
+![](assets/20220116_174115_Circle2.png)
+
+*Sintaxis*
+
+```
+SELECT campo from tabla
+EXCEPT
+SELECT otrocampo from otratabla
+```
+
+En mysql no se encuentra la instruccion except en algunos otros dbms se utiliza minus en mysql se suele usar para esta tarea NOT IN, NOT EXIST o inluso con un LEFT OUTER JOIN
+
+*Sintaxis*
+
+```
+SELECT campo from tabla
+WHERE campo NOT IN 
+(SELECT otrocampo from otratabla)
+```

conjuntos/consultas.sql

@@ -0,0 +1,25 @@
+CREATE TABLE tabla1 (
+    id INT PRIMARY KEY
+);
+
+CREATE TABLE tabla2 (
+    id INT PRIMARY KEY
+);
+
+
+INSERT INTO tabla1(id) VALUES(1),(2),(3);
+
+INSERT INTO tabla2(id) VALUES(2),(3),(4);
+
+#union
+select id from tabla1
+union
+select id from tabla2
+
+#intersec
+select id from tabla1
+where id in (select id from tabla2)
+
+#except
+select id from tabla1
+where id not in (select id from tabla2)

joins/consultas.sql

@@ -0,0 +1,8 @@
+select * 
+from categorias c 
+join categoria_producto cp on c.id = cp.categoria_id 
+join productos p on p.id = cp.producto_id 
+
+select c.id, c.nombre, c.categoria_id ,c2.nombre from categorias c 
+join categorias c2 on c2.id = c.categoria_id  
+

joins/joins.md

@@ -0,0 +1,87 @@
+# JOINS
+
+Los join se usan para recuperar datos de varias tablas al mismo tiempo y las tablas tienen que estar relacionadas de algún modo, normalmente mediante un id.
+
+En Mysql, como en la mayoría de las bases de datos relacionales hay diferentes tipos de join.
+
+## INNER JOIN
+
+También se puede usar como **join** sin nada más. En este caso la sentencia va a devolver los datos que existen las dos tablas que se comparan.
+
+![](assets/20220116_191801_img_innerjoin.gif)
+
+*Sintaxis*
+
+```
+SELECT column_name(s)
+FROM table1
+INNER JOIN table2
+ON table1.column_name = table2.column_name;
+```
+
+### Implementación
+
+*Sintaxis*
+
+```
+select c.id, c.nombre, c.categoria_id ,c2.nombre from categorias c 
+join categorias c2 on c2.id = c.categoria_id  
+```
+
+Tambien se pueden relacionar mas de dos tablas
+
+```
+select *
+from categorias c
+join categoria_producto cp on c.id = cp.categoria_id
+join productos p on p.id = cp.producto_id
+```
+
+## LEFT JOIN
+
+En este caso la sentencia va a devolver los datos que tiene en la primera tabla con los datos que tiene en común con la segunda tabla.
+
+![](assets/20220116_192640_img_leftjoin.gif)
+
+*Sintaxis*
+
+```
+SELECT column_name(s)
+FROM table1
+LEFT JOIN table2
+ON table1.column_name = table2.column_name;
+```
+
+## RIGHT JOIN
+
+Este caso es como el anterior pero a la inversa, la sentencia va a devolver los datos que tiene en la segunda tabla con los datos que tiene en común con la primera tabla.
+
+![](assets/20220116_192835_img_rightjoin.gif)
+
+*Sintaxis*
+
+```
+SELECT column_name(s)
+FROM table1
+RIGHT JOIN table2
+ON table1.column_name = table2.column_name;
+```
+
+## OUTER JOIN o FULL OUTER JOIN
+
+En este caso se recuperan todos los datos de ambas tablas. Este tipo de join no es compatible con MySQL y para conseguir un OUTER JOIN hay que usar la unión de sentencias con UNION del INNER JOIN y del LEFT JOIN.En MySQL los UNION tienen que tener el mismo número de campos en el SELECT sino dará error.
+
+
+![](assets/20220116_204403_img_fulljoin.gif)
+
+*Sintaxis*
+
+```
+SELECT column_name(s)
+FROM table1
+FULL OUTER JOIN table2
+ON table1.column_name = table2.column_name
+WHERE condition;
+```
+
+Para implementarlo en MYSQl tendriamos que usar la union del left join y del right join

optimizacion/indices.md

@@ -0,0 +1,31 @@
+# Indices
+
+Indexar un campo en una tabla de la base de datos solo sirve para mejorar la velocidad de busqueda y querys donde se relacione ese campo.
+
+Para hacerlo hay dos maneras.
+
+- Indexar permitiendo valores duplicados
+
+*Sintaxis*
+
+```
+CREATE INDEX index_name
+ON table_name (column1, column2, ...);
+```
+
+- Indexar solo permitiendo valores unicos
+
+*Sintaxis*
+
+```
+CREATE UNIQUE INDEX index_name
+ON table_name (column1, column2, ...);
+```
+
+Para eliminar un indices
+
+*Sintaxis*
+```
+ALTER TABLE table_name
+DROP INDEX index_name;
+```

optimizacion/rendimiento.md

@@ -0,0 +1,114 @@
+# Saber peso de nuestras base de datos
+
+Es importante poder conocer el tamaño que ocupan nuestras base de datos y tablas para poder definir donde hay gran cantidad de datos y por ende hay que realizar optimizacion
+
+*Sintaxis*
+```
+SELECT table_schema AS "Base de datos",
+ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS "Tamaño (MB)"
+FROM information_schema.TABLES
+GROUP BY table_schema;
+```
+
+Saber el peso de una tablas
+
+*Sintaxis*
+```
+SELECT table_name AS "Tabla",
+ROUND(((data_length + index_length) / 1024 / 1024), 2) AS "Tamaño (MB)"
+FROM information_schema.TABLES
+WHERE table_schema = "base_de_datos"
+ORDER BY (data_length + index_length) DESC;
+```
+
+# Mejorar rendimiento de campos que guardan UUID
+
+Lo estandar es guardar campos que guardar uuid en varchar de 32 o incluso en char de 32 pero por alguna razon cuando se guarda en campos de tipo binario el rendimiento mejora considerablemente y si ademas indexamos el campos el rendimiento es hasta 160% mas rapido que si lo guardamos en tipo texto.
+
+# SLOW QUERY
+
+Para Permitirnos ver las querys que estan tomando mucho tiempo en realizarse en el servidor y que por ende nos estan causando problemas de rendimiento lo podremos activar en el archivo de configuracion my.cnf, pero tambien podremos activarlo desde una consulta.
+
+*Sintaxis*
+```
+SET GLOBAL slow_query_log = 'ON';
+```
+
+Por defaul cualqueir consulta que dure mas de 10 segunos sera registrada, podemos cambiar ese tiempo usando la siguiente instrucción.
+
+*Sintaxis*
+```
+SET GLOBAL long_query_time = TIEMPO;
+```
+
+Para desactivarlo solo tendremos que hacer esta consulta. Cuando
+
+*Sintaxis*
+```
+SET GLOBAL slow_query_log = 'OFF';
+```
+
+# Reparación de bases de datos dañadas
+
+Mysql tiene basicamente dos motores de base de datos MyISAM e InnoDB por desgracia la forma de repararlas no es la misma asi que listo rapidamente las dos maneras de realizar estas tareas
+
+## AMBOS
+
+Tendras que detener el servicio de base de datos dependiedo de la distribucion de SO que tengas.
+
+En esta parte recomiendo en sacar un respaldo de los archivos data de tu base de datos, esto tambien dependera del SO anfitrion de tu servidor de base de datos.
+
+Si quieres verificar toda una base de datos usaras el siguiente comando.
+
+```
+mysqlcheck base_de_datos
+```
+
+Si solo quieres verificar una tabla seria el siguiente:
+
+```
+mysqlcheck base_de_datos tabla
+```
+
+En ambos casos indicara si la tabla contiene algun error si no mostrara ok alado de la tabla.
+
+En caso de requerir reparacion el mismo comando que usaste pero con el parametro -r hara la reparacion quedando d ela siguiente manera:
+
+```
+mysqlcheck -r base_de_datos tabla
+```
+
+## MyISAM
+
+Para una repacaion mas especializada podras en caso de usar este motor usar la herramienta **myisamchk** la cual trabbaja con archivos asi que tendras que indicar el archivo con extencion .MYI de la tabla que quieres reparar tambien puedes indicarle *.MYI para que lo haga en todas las tablas.
+
+Si el comando logra encontrar alguna tabla con fallo ejecutarias el siguiente comando para repararla.
+```
+myisamchk --recover tabla
+```
+
+## InnoDB
+
+Para el caso de InnoDB se tiene que hacer un cmabio en el archivo de configuración, por supuesto con el servicio de la base de datos apagado.
+```
+innodb_force_recovery=4
+```
+dentro del archivo de configuracion my.cnf
+
+luego usando **mysqldump** habria que respaldar las base de datos
+```
+mysqldump --all-databases --add-drop-database --add-drop-table > bases_de_datos.sql
+```
+
+Despues abria que borra la base de datos y restaurar el respaldo que hicimos, para finalizar comentando de nuevo la configuracion hecha en el archivo my.cnf 
+```
+mysql < bases_de_datos.sql
+```
+```
+#innodb_force_recovery=4
+```
+
+para mas informacion el link de la documentación oficial
+
+[Documentacion Oficial](https://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html)
+

transacciones/transacciones.md

@@ -0,0 +1,81 @@
+# Transacciones
+
+Una transacción en un Sistema de Gestión de Bases de Datos es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.
+
+Se dice que un SGBD es transaccional si es capaz de mantener la integridad de los datos, haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad), como si la orden de la transacción nunca se hubiese realizado. Una transacción debe contar con ACID (un acrónimo inglés) que quiere decir: Atomicidad, consistencia, aislamiento y durabilidad.
+
+MySQL es compatible con varios motores de almacenamiento. InnoDB es totalmente compatible con ACID. Las transacciones confiables deben ser compatibles con estas cuatro propiedades.
+
+Las operaciones dentro de una transacción deben ser atómicas. Esto significa que todas las operaciones tienen éxito o fallan. Esta es la regla de todo o nada. La consistencia garantiza que la base de datos se encuentre en un estado consistente una vez finalizada la transacción, los datos son válidos y no hay registros a medio terminar. Por ejemplo, no quedan clientes sin registros de pago o no hay registros de pago sin clientes.
+
+El aislamiento es el requisito de que otras operaciones no puedan acceder a los datos que se han modificado durante una transacción que aún no se ha completado, el aislamiento ocurre en caso de transacciones concurrentes. Sin aislamiento, los datos pueden terminar en un estado inconsistente. La durabilidad es la capacidad del sistema de base de datos para poder recuperarse en caso que se presenten transacciones comprometidas contra cualquier tipo de falla del sistema.
+
+## Niveles de aislamiento
+
+Pues bien, repasado este concepto ya podemos mostrar los problemas asociados a los distintos tipos de transacciones:
+
+* ### Dirty reads (Lecturas sucias)
+
+Es el problema más importante de todos. Supone que las transacciones en curso puedan leer el resultado de otras transacciones aún no confirmadas. Por ejemplo, vamos a suponer que tenemos dos transacciones activas (A y B).
+
+Inicialmente la transacción A lee un valor X de una tabla que, por ejemplo, es 0. Durante dicha transacción el valor de X se cambia a 10, pero aún la transacción no se ha completado, por lo que en la tabla X = 0. Ahora la transacción B accede al valor X y obtiene X = 10 un valor que está usando A y que aún no se ha cometido. Supongamos que ahora se anula la transacción A. El resultado sería X = 0 en la tabla y X = 10 en la transacción B por lo que hemos llegado a un estado muy grave de inconsistencia.
+
+* ### Non-Repeatable reads (Lecturas no repetibles)
+
+Ocurre cuando una transacción activa vuelve a leer un dato cuyo valor difiere con respecto al de la anterior lectura. Lo vemos más claro con un ejemplo.
+
+Supongamos que una transacción activa, A, lee un valor X = 0. En este momento otra transacción B modifica el valor de X, por ejemplo X = 10, y se comete dicha transacción. Si ahora durante la transacción A se vuelve a leer el valor X obtendríamos 10 en lugar del 0 que se esperaba. Aunque a primera vista este problema no parezca muy importante en realidad sí que lo es, sobre todo cuando X es una clave primaria o ajena. En este caso se puede originar una gran pérdida de consistencia en nuestra base de datos.
+
+* ### Phantom reads (Lecturas fantasma)
+
+Este supone el menor problema que se nos puede plantear con respecto a las transacciones. Sucede cuando una transacción en un momento lanza una consulta de selección con una condición y recibe en ese momento N filas y posteriormente vuelve a lanzar la misma consulta junto con la misma condición y recibe M filas con M > N. Esto es debido a que durante el intervalo que va de la primera a la segunda lectura se insertaron nuevas filas que cumplen la condición impuesta en la consulta.
+
+Debido a estos problemas el ANSI establece diferentes niveles de aislamiento (isolations levels) para solventarlos. Hay que tener en cuenta que a mayor nivel de aislamiento mayores son los sacrificios que se hacen con respecto a la concurrencia y al rendimiento. Vamos a enumerar los niveles de aislamiento desde el menor hasta el mayor:
+
+- Read uncommitted (Lectura sin confirmación): En la práctica casi no se suele utilizar este nivel de aislamiento ya que es propenso a sufrir todos los problemas anteriormente descritos. En este nivel una transacción puede ver los resultados de transacciones aún no cometidas. Podemos apreciar que en este nivel no existe aislamiento alguno entre transacciones.
+- Read committed (Lectura confirmada): Es el predeterminado para la mayoría de gestores de bases de datos relacionales. Supone que dentro de una transacción únicamente se pueden ver los cambios de las transacciones ya cometidas. Soluciona el problema de las lecturas sucias, pero no el de las lecturas no repetibles ni tampoco el de las lecturas fantasmas.
+- Repeatable read (Lectura repetible): Define que cualquier tupla leída durante el transcurso de una transacción es bloqueada. De esta forma se soluciona, además de las lecturas sucias, el problema de las lecturas no repetibles. Aunque en dicho nivel se siguen dando las lecturas fantasmas.
+- Serializable (Lecturas en serie): Soluciona todos los problemas descritos. Para ello ordena las transacciones con el objetivo de que no entren en conflicto. Este nivel de aislamiento es bastante problemático ya que es, con diferencia, el que más sacrifica en rendimiento y concurrencia.
+
+
+
+| Nivel de aislamientocol | Lecturas fantasma | Lecturas no repetibles | Lecturas sucias |
+| :---------------------- | :---------------: | :--------------------: | :-------------: |
+| Serializable            | No                | No                     | No              |
+| Repeatable read         | Si                | No                     | No              |
+| Read committed          | Si                | Si                     | No              |
+| Read uncommitted        | Si                | Si                     | Si              |
+
+Para consultar que nivel de aislamiento se esta usando
+
+```
+SELECT @@tx_isolation;
+```
+
+Para cambiarlo por otro por:
+
+```
+SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
+```
+
+## Autocommit
+
+MySQL ejecuta automáticamente las consultas que no son parte de una transacción. Los resultados de cualquier consulta ya sea ACTUALIZAR o INSERTAR que no esté precedida por un START TRANSACTION (BEGIN) serán visibles inmediatamente para todas las conexiones.
+
+podemos ver el modo en el que se encuentra una conexion con esta consulta
+
+```
+SELECT @@autocommit;
+```
+
+con esta consulta podemos  desactivarla
+
+```
+SET autocommit=0;
+```
+
+y colocando el valor 1 la activariamos de nuevo
+
+## Manejo de transacciones
+
+Con autocommit habilitado, cada instrucción SQL se ajusta automáticamente en su propia transacción. Para comenzar nuestra propia transacción, debemos ejecutar la instrucción START TRANSACTION (BEGIN). La transacción se termina más tarde con las instrucciones COMMIT o ROLLBACK. Se pueden ejecutar múltiples declaraciones en el cuerpo de la transacción.

triggers/triggers.md

@@ -0,0 +1,59 @@
+# Triggers
+
+Técnicamente, un trigger es un objeto de una base de datos que está asociado a una tabla, y que será activado cuando la acción que tiene asociada tiene lugar. 
+
+El trigger se puede ejecutar cuando tiene lugar una acción INSERT, UPDATE o DELETE, siendo posible su ejecución tanto antes como después del evento.
+
+*Sintaxis*
+
+```
+CREATE
+    [DEFINER = { user | CURRENT_USER }]
+    TRIGGER trigger_name
+    trigger_time trigger_event
+    ON tbl_name FOR EACH ROW
+    [trigger_order]
+    trigger_body
+```
+**Explicación**
+* DEFINER: Especifica el usuario de BBDD con privilegios para desencadenar un TRIGGER. Por defecto es el usuario que crea el TRIGGER.
+* trigger_name: Nombre del TRIGGER/disparador.
+* trigger_time: Especifica cuando se ha de ejecutar el TRIGGER, antes o después del evento detectado.
+* trigger_event: Evento que activa el TRIGGER –> INSERT, UPDATE y DELETE.
+* tbl_name: Nombre de la tabla en la que detectaremos el trigger_event.
+* trigger_order: Una tabla puede tener asociados varios TRIGGER, por defecto la ejecución de cada uno es el orden en el que fuero creados. Para alterar ese orden podemos definirlos con FOLLOWS (depués de nombre trigger) y con PRECEDE (antes de nombre_trigger).
+* trigger_body: Código del TRIGGER.
+
+## Implementación
+
+hagamos un triger que al definir un precio de compra indique que el precio de venta es un 16% mas para incrementarle el IVA del producto.
+
+```
+DELIMITER $$
+$$
+CREATE TRIGGER actualizar_precio_productos
+BEFORE UPDATE
+ON productos FOR EACH row
+BEGIN
+  IF NEW.preciocompra <> OLD.preciocompra
+    THEN
+      SET NEW.precio = NEW.preciocompra * 1.16;
+  END IF ;
+END
+$$
+DELIMITER ;
+```
+
+Verificar que este funcionando el trigger
+
+```
+SELECT * FROM productos WHERE id = 6;
+UPDATE productos SET preciocompra = 100 WHERE id = 6;
+SELECT * FROM productos WHERE id = 6;
+```
+
+## Eliminar un trigger
+
+```
+DROP TRIGGER nombre_del_trigger
+```