1
00:00:00,000 --> 00:00:08,460
y lo interpreta como con este delimiter que tiene que leerlo todo en bloque y no ejecutarlo de manera

2
00:00:08,460 --> 00:00:14,519
fraccionada es como decirle al cliente durante un momento no interpreta ese punto y coma como

3
00:00:14,519 --> 00:00:21,280
final de comando espera que acabe el delimitador un ejemplo sería este que aparece aquí que sería

4
00:00:21,280 --> 00:00:25,679
veis lo que hace hemos creado un procedimiento que se llama simple pro que tiene un parámetro

5
00:00:25,679 --> 00:00:28,100
de salida que se llama param1 y que es de tipo entero

6
00:00:28,100 --> 00:00:31,780
y cuyo cuerpo generado entre el begin

7
00:00:31,780 --> 00:00:35,020
y el end, esto podría simular la llave

8
00:00:35,020 --> 00:00:37,380
de apertura y de cierre en cualquier lenguaje de programación

9
00:00:37,380 --> 00:00:40,799
de un procedimiento o una función, dentro tiene una sentencia

10
00:00:40,799 --> 00:00:42,899
que se llama, que sería, cuéntame

11
00:00:42,899 --> 00:00:46,920
el número de la tabla T

12
00:00:46,920 --> 00:00:50,259
el número de registros que tiene y me lo metes

13
00:00:50,259 --> 00:00:52,840
into en el parámetro de salida que hemos

14
00:00:52,840 --> 00:00:55,420
introducido aquí, con lo cual al final nos va a dar

15
00:00:55,420 --> 00:00:57,579
el resultado de este parámetro.

16
00:00:58,200 --> 00:01:00,439
El delimiter no cambia SQL en sí,

17
00:01:00,600 --> 00:01:03,060
cambia cómo el cliente detecta el final del comando.

18
00:01:03,439 --> 00:01:05,280
Es esencial cuando hay procedimientos y triggers

19
00:01:05,280 --> 00:01:06,879
con bloques múltiples.

20
00:01:07,500 --> 00:01:08,959
No es que el servidor necesite otro lenguaje,

21
00:01:09,120 --> 00:01:11,599
sino que el cliente necesita una señal distinta

22
00:01:11,599 --> 00:01:15,700
para no cortar la definición antes de tiempo.

23
00:01:21,500 --> 00:01:23,200
En cuanto a la invocación externa,

24
00:01:23,859 --> 00:01:25,799
bueno, esto sería, pues, nos ha sometido un poco,

25
00:01:25,799 --> 00:01:28,579
muestra cómo una aplicación PHP interactúa con MySQL

26
00:01:28,579 --> 00:01:29,439
en tres pasos.

27
00:01:29,439 --> 00:01:33,480
primero realiza, veis, con PHP realiza la conexión con la base de datos

28
00:01:33,480 --> 00:01:35,280
a través de su localhost y root

29
00:01:35,280 --> 00:01:38,060
posteriormente es la selección de la base de datos

30
00:01:38,060 --> 00:01:40,219
qué tipo va a seleccionar

31
00:01:40,219 --> 00:01:44,819
y por último ejecuta a través de call

32
00:01:44,819 --> 00:01:49,519
veis este procedimiento almacenado que tiene estos tres parámetros de entrada

33
00:01:49,519 --> 00:01:53,219
la aplicación no necesita saber cómo está implementada

34
00:01:53,780 --> 00:01:56,819
toda la lógica simplemente lo que hace es que llama al procedimiento

35
00:01:56,819 --> 00:02:04,879
Aquí vemos cómo una aplicación PHP se comunica con el procedimiento almacenado, primero abre la conexión con MySQL, después selecciona la base de datos y, por último, ejecuta una llamada call.

36
00:02:06,159 --> 00:02:11,080
Entonces, la aplicación no necesita saber todos los detalles internos de la lógica, solo pasa parámetros y recoge el resultado.

37
00:02:14,319 --> 00:02:22,919
Esta lógica favorece, lógicamente, el encasulamiento. La lógica está escondida detrás de una interfaz simple. La aplicación consume servicios de la base de datos.

38
00:02:22,919 --> 00:02:45,379
Si desde PHP queremos insertar una persona, podríamos llamar al procedimiento, por ejemplo, SP-insertarPersona. Desde el punto de vista de PHP, da igual si por dentro ese procedimiento hace una sola inserción o cinco comprobaciones adicionales. PHP solo lo invoca.

39
00:02:45,379 --> 00:02:58,879
Aquí introducimos, una vez que hemos hablado a nivel sencillo de cómo es la estructura de un procedimiento almacenado y para qué sirven, vamos a ver los disparadores o triggers. Los triggers son como objetos ligados a tablas que se ejecutan automáticamente.

40
00:02:58,900 --> 00:03:17,020
Pero se ejecutan, de ahí la palabra trigger, cuando ocurre un evento determinado, pues tenemos que se van a ejecutar. También se dice que encasulan, que es el encasulamiento de acciones dentro de un beginning. Son ideales para auditoría o rastreo de actividades.

41
00:03:17,020 --> 00:03:34,900
Entonces, un trigger no se ejecuta manualmente con call, como pasaba con el procedimiento almacenado, sino que ahora un trigger lo que se activa es cuando ocurre un evento y ese evento siempre va a ser fundamentado cuando ocurre un insert, cuando ocurre un update y cuando ocurre un delete sobre una tabla concreta.

42
00:03:34,900 --> 00:03:41,939
Por ejemplo, mientras que un procedimiento almacenado se ejecuta cuando alguien lo invoca expresamente, un trigger funciona como un piloto automático.

43
00:03:42,539 --> 00:03:47,360
Está asociado a una tabla y se activa automáticamente cuando ocurre un evento, como una inserción, una actualización o un borrado.

44
00:03:48,719 --> 00:03:56,259
La diferencia clave es que el procedimiento es una ejecución explícita, mientras que el trigger es una ejecución automática y reactiva.

45
00:03:57,120 --> 00:04:01,580
Ejemplo muy bueno sería si una empresa quiere registrar en una tabla de auditoría

46
00:04:01,580 --> 00:04:03,759
cada vez que se modifica el sueldo de un empleado,

47
00:04:04,120 --> 00:04:07,879
no hace falta confiar en que el programador se acuerde de registrar ese cambio

48
00:04:07,879 --> 00:04:10,580
en todos los puntos de la aplicación, sino que se crea un trigger

49
00:04:10,580 --> 00:04:14,259
sobre el update asociado a esa tabla.

50
00:04:14,259 --> 00:04:16,120
Y la base de datos lo hará siempre.

51
00:04:16,720 --> 00:04:20,519
Si alguien inserta una venta, un trigger puede rellenar automáticamente

52
00:04:20,519 --> 00:04:25,980
la fecha de registro, generar un log o validar ciertos datos antes de guardar.

53
00:04:26,259 --> 00:04:34,420
Los triggers convierten la base de datos en un sistema reactivo, no espera que la llamen, responde automáticamente a eventos.

54
00:04:37,850 --> 00:04:58,649
Esto combina lo anterior, tenemos los eventos en el que serían insert, update y delete y los momentos en el que se pueden producir y que se definirán en un trigger o si es antes de que se produzca un insert, un update o un delete que sería a través de before o after, después el evento se producirá después de que se produzca un insert, un update o un delete.

55
00:04:59,550 --> 00:05:04,889
El BEFORE valida antes de tocar disco, el LASTER escribe en auditorías de forma segura.

56
00:05:05,990 --> 00:05:08,769
Por tanto, BEFORE se ejecuta antes que el cambio sea efectivo.

57
00:05:09,310 --> 00:05:12,990
¿Para qué sirve? Para validar datos, corregir valores, impedir operaciones,

58
00:05:13,649 --> 00:05:16,550
modificar en NEW en ciertos casos, ahora lo veremos,

59
00:05:16,889 --> 00:05:19,730
y el LASTER se ejecuta después de que un cambio sea realizado.

60
00:05:19,730 --> 00:05:23,129
Sirve para auditoría, trazabilidad, sincronización, acciones posteriores.

61
00:05:27,819 --> 00:05:30,319
Un trigger no solo reacciona a un tipo de operación,

62
00:05:30,319 --> 00:05:50,720
También puede definirse según el momento en que actúa. Si es before, actúa antes de que el dato se escriba. Si es after, actúa cuando el cambio ya se ha realizado. Esta combinación genera una matriz muy útil. Before insert, after insert, before update, after update y así sucesivamente.

63
00:05:50,720 --> 00:06:19,379
Ejemplos, por ejemplo, un before insert, pues sería antes de guardar un nuevo producto, puedo comprobar que el precio no sea negativo. After insert, pues después de insertar una nueva venta, puedo registrar ese hecho en una tabla de auditoría. Before update, antes de cambiar el stock, puedo impedir que quede por debajo de cero. O after delete, después de borrar un cliente, pues puedo guardar una copia de sus datos eliminados en una tabla de histórico.

64
00:06:20,720 --> 00:06:26,839
Por tanto, BEFORE sirve para controlar o modificar, AFTER sirve para reaccionar y dejar constancia.

65
00:06:29,850 --> 00:06:40,170
Aquí tenemos la anatomía de un disparador, cómo es su estructura, igual que CREATE PROCEDURE, aquí es CREATE TRIGGER y el nombre del disparador.

66
00:06:40,910 --> 00:06:45,990
Después tenemos el momento del disparo, en el que va a ser BEFORE o AFTER, que es lo que hemos definido anteriormente.

67
00:06:45,990 --> 00:07:00,910
Luego el evento del disparo, que sea un insert, un update, un delete. Luego el on, que es el objetivo a observar y con el nombre de la tabla y por cada una de las filas, for each row, la sentencia que se va a disparar o la acción que vamos a querer ejecutar.

68
00:07:00,910 --> 00:07:04,269
aquí tenemos por ejemplo

69
00:07:04,269 --> 00:07:05,670
la eliminación del trigger

70
00:07:05,670 --> 00:07:07,709
como eliminar dicho trigger

71
00:07:07,709 --> 00:07:12,029
¿qué significa

72
00:07:12,029 --> 00:07:13,970
todo esto?

73
00:07:14,089 --> 00:07:16,009
esto sería lo que llamamos la estructura

74
00:07:16,009 --> 00:07:17,990
en cuanto a todo lo que vemos aquí

75
00:07:17,990 --> 00:07:19,810
esto sería lo nuevo

76
00:07:19,810 --> 00:07:22,350
que sería el onTabla

77
00:07:22,350 --> 00:07:23,970
forEachRow, que significa que

78
00:07:23,970 --> 00:07:26,449
el trigger se aplica a cada fila afectada

79
00:07:26,449 --> 00:07:28,029
la sentencia disparada

80
00:07:28,029 --> 00:07:28,990
sería la lógica

81
00:07:28,990 --> 00:07:32,689
que sería la lógica que va a ejecutar cuando se produzca el evento.

82
00:07:33,209 --> 00:07:35,750
La estructura de un disparador es bastante directa.

83
00:07:35,889 --> 00:07:39,629
Se declara el Create Trigger, se indica si actúa antes o después del evento,

84
00:07:39,810 --> 00:07:42,430
se especifica el tipo de operación que lo activa,

85
00:07:42,850 --> 00:07:47,410
se asocia a una tabla y se define la acción que se ejecutará por cada fila afectada.

86
00:07:48,250 --> 00:07:52,430
Es muy importante explicar bien que si una sentencia afecta a 10 filas,

87
00:07:52,490 --> 00:07:55,889
el trigger se dispara 10 veces, una por cada fila. Cuida con eso.

88
00:07:55,889 --> 00:08:11,889
Un ejemplo, pues tendríamos si ejecuto un update que modifica, por ejemplo, el precio de 100 productos, un trigger for each row actuará 100 veces una vez por cada fila modificada.

89
00:08:11,889 --> 00:08:41,669
Por eso hay que diseñarlo con cuidado, porque puede tener un impacto en el rendimiento muy grande. Un ejemplo de disparador podría ser el Create Trigger, por ejemplo, auditoría. Podríamos poner After Insert, o sea, se va a producir después del insertado, y luego pondríamos On Ventas, afectaría a la tabla de ventas, y por cada fila, For Each Row, vamos a hacer una ejecución que será Insert Into Auditoria, el determinado de los valores.

90
00:08:41,889 --> 00:08:59,820
Veis, cada vez que se produzca, después de que haya una inserción en la tabla ventas, se va a producir una inserción en la tabla de auditoría de una serie de valores para que quede reflejado.

91
00:08:59,820 --> 00:09:12,519
Aquí tenemos el paradigma temporal con el all y el new. Aquí se explica dos términos o dos palabras clave que serían el all, que sean valores antes del cambio, y el new, que sean valores después del cambio.

92
00:09:13,200 --> 00:09:15,980
Se especifica el insert, el update y el delay.

93
00:09:16,340 --> 00:09:18,879
Lógicamente, el insert solo permite el new.

94
00:09:19,080 --> 00:09:21,620
Hemos visto que el new son valores después del cambio.

95
00:09:22,580 --> 00:09:25,320
El update permitirá all y new,

96
00:09:25,659 --> 00:09:28,179
mientras que el delay solo permitirá all,

97
00:09:28,980 --> 00:09:30,139
cuando ya se ha borrado.

98
00:09:31,039 --> 00:09:32,519
Además, aparece una nueva sentencia,

99
00:09:32,600 --> 00:09:35,179
que sería esta de aquí, que no se ve ahora.

100
00:09:35,799 --> 00:09:37,159
Ahora, sería la de abajo,

101
00:09:37,299 --> 00:09:40,740
que pone set new actor igual a Robert De Niro.

102
00:09:42,519 --> 00:09:57,100
Esto lo que nos va a colocar es que cuando se realice, por ejemplo, el insert, el nuevo, el nuevo, el new punto actor, el nuevo actor, me coloque el rover de Nero.

103
00:09:58,100 --> 00:10:03,500
Hay un antes y un después. El old sería el valor previo, mientras que el new sería el valor modificado.

104
00:10:03,919 --> 00:10:10,299
En delete, tras borrar, no existe ningún valor persistente. Por eso solo se usa el old.

105
00:10:10,299 --> 00:10:29,000
Entonces, por tanto, all y new son referencias al estado de la fila dentro de un trigger. Entonces, el all representa cómo estaba antes del cambio. El new, cómo quedará después. Hay las palabras all, dato anterior, new, dato nuevo.

106
00:10:29,720 --> 00:10:32,480
Dependiendo del evento, una u otra estarán disponibles.

107
00:10:32,480 --> 00:10:38,580
En un insert solo tiene sentido new, en un delete, en un insert un new.

108
00:10:39,220 --> 00:10:42,279
¿Por qué? Porque va a ser el nuevo dato que se va a insertar.

109
00:10:42,639 --> 00:10:46,220
En un delete solo el old, porque cuando se borre ya no habrá nuevo dato,

110
00:10:46,320 --> 00:10:50,059
sino que se borrará y podremos hacer referencia al dato que antes existía.

111
00:10:50,340 --> 00:10:52,240
En el update podemos utilizar ambos.

112
00:10:53,179 --> 00:10:57,480
Un update, por ejemplo, si antes el sueldo era 1.200

113
00:10:57,480 --> 00:11:02,299
y después pasa a 1.500, el odd.sueldo será 1.200,

114
00:11:02,559 --> 00:11:05,360
mientras que el new.sueldo será 1.500.

115
00:11:05,559 --> 00:11:07,220
Esto permite detectar cambios.

116
00:11:07,779 --> 00:11:10,639
Entre el insert, por ejemplo, tendríamos cuando insertamos un nuevo usuario,

117
00:11:11,159 --> 00:11:16,639
podemos acceder al new.email, a su email, para validarlo o normalizarlo.

118
00:11:16,940 --> 00:11:21,779
Y en el delete, si eliminamos un pedido, podemos guardar el odd.id pedido

119
00:11:21,779 --> 00:11:25,600
o el odd.total en una tabla, por ejemplo, de borrados.

120
00:11:25,600 --> 00:11:41,120
¿Veis por qué el All y el New aparecen de manera diferente en Insert, Update y Delay? Porque son acciones diferentes. Entonces, All y New convierten el trigger en una especie de observador del antes y del después de cada fila.

121
00:11:41,120 --> 00:12:07,100
Bueno, esta diapositiva lo que demuestra es lo que es la automatización de comisiones en el que tiene todos los pasos, en el que en principio tenemos el evento en el que inserta dentro de ventas los valores de queso y de 300.

122
00:12:07,100 --> 00:12:25,539
El segundo paso sería el sensor, en el que tenemos un trigger, en el que queremos que se realice antes de que se produzca la inserción y se va a activar. Y la delegación, que sería el llamar a comisión, que sería el trigger, capturando el nuevo valor.

123
00:12:25,539 --> 00:12:37,200
Se activa el cálculo, es el procedimiento que calcula el 10% y se lo asigna a arroba.com, que sería el parámetro de salida.

124
00:12:37,639 --> 00:12:43,299
Y luego la modificación, colocamos la nueva comisión, o sea, lo que ha insertado dentro de esa variable.

125
00:12:43,940 --> 00:12:50,860
Y por último tenemos la escritura del registro que se guarda como una comisión almacenada, que serían los tres valores.

126
00:12:50,860 --> 00:13:03,340
Por tanto, el trigger se utiliza para detectar automáticamente el evento y el procedimiento almacenado, porque estamos utilizando dos, para encasular el cálculo.

127
00:13:03,580 --> 00:13:07,679
Es decir, el trigger actúa como detector y el procedimiento como calculadora especializada.

128
00:13:07,679 --> 00:13:21,139
¿Veis? Esto va a detectar cuando se produce una inserción y cuando se produce una inserción dentro del trigger llama a un procedimiento almacenado que sería el procedimiento commission.

129
00:13:21,139 --> 00:13:39,340
Pero no solo la llama, la llama con un parámetro que además es el valor nuevo que ha sido insertado y que ha sido recogido a través del trigger. Lo veis, lo mete como un parámetro de entrada y para que luego ese procedimiento realice el cálculo. Una vez que el cálculo se ha realizado, ese parámetro, ese cálculo lo devuelve como un valor.

130
00:13:39,340 --> 00:13:56,639
Veis aquí con el arroba com y ese es el que va a alojar el valor de la nueva comisión. Aquí vemos una automatización completa. Cuando se inserta una venta, el trigger before insert se activa automáticamente.

131
00:13:56,639 --> 00:14:14,100
En lugar de hacer todo el cálculo directamente dentro del trigger, delega ese trabajo a un procedimiento almacenado llamado comisión y ese procedimiento calcula el 10% del valor de venta. Guarda el resultado y luego el trigger asigna ese valor al campo comisión antes de que el registro se escriba definitivamente.

132
00:14:18,879 --> 00:14:25,519
Esto es una arquitectura limpia, el trigger desde tal momento, el procedimiento concentra la lógica y el resultado se integra antes de guardar.

133
00:14:25,659 --> 00:14:35,080
Si insertamos una venta de 300 euros de queso, el trigger se activa antes de guardar, entonces llama al procedimiento de comisión que calcula el 10%, que es 30 euros.

134
00:14:35,240 --> 00:14:40,019
Después el trigger coloca ese valor en el campo comisión y finalmente el registro se almacena ya completo.

135
00:14:41,379 --> 00:14:46,120
Por tanto, esto evita depender de que la aplicación recuerde calcular la comisión.

136
00:14:46,120 --> 00:15:11,100
La base de datos garantiza que siempre se haga. Aquí tenemos la comparación entre los procedimientos almacenados y los disparadores. Una sería en cuanto al modo de ejecución, en el que un procedimiento almacenado hay que llamarle de manera explícita, a través de call, mientras que un disparador es un evento autónomo, irreactivo.

137
00:15:11,100 --> 00:15:15,919
O sea, cuando ocurre algo que nosotros queremos o salta ese evento, pues se dispara.

138
00:15:16,860 --> 00:15:23,320
En cuanto a las variables de contexto, los parámetros que se pueden meter dentro de un parámetro almacenado serían el in, el out y el in-out.

139
00:15:23,720 --> 00:15:27,019
Mientras que las palabras clave dentro de un trigger serían el old y el new.

140
00:15:27,600 --> 00:15:35,019
Luego la interacción con la aplicación puede ser invocado directamente por PHP y en cambio un disparador es totalmente invisible para la aplicación.

141
00:15:35,019 --> 00:15:42,360
Un caso de uso ideal, por ejemplo, la lógica de negocio, sería la que se utilizaría para los procedimientos almacenados.

142
00:15:42,779 --> 00:15:45,779
Auditoría, validación y cálculos derivados serían para el trigger.

143
00:15:46,379 --> 00:15:50,879
La última diapositiva resume cuándo conviene usar cada mecanismo.

144
00:15:51,340 --> 00:15:56,480
Los procedimientos almacenados se ejecutan de forma explícita, normalmente mediante una llamada desde la aplicación,

145
00:15:56,820 --> 00:16:00,259
y son ideales para encasular lógica de negocio más elaborada.

146
00:16:00,259 --> 00:16:09,440
Los triggers, en cambio, reaccionan automáticamente ante cambios en los datos y resultan especialmente útiles para validaciones, auditoría y cálculos derivados.

147
00:16:11,539 --> 00:16:18,580
Si quiero pedirle algo a la base de datos, uso un procedimiento. Si quiero que la base de datos reaccione sola ante un cambio, uso un trigger.

148
00:16:19,899 --> 00:16:27,519
Procedimiento, un ejemplo, quiero generar un informe de ventas mensuales agrupado por regiones. Eso encaja mejor en un procedimiento almacenado.

149
00:16:27,519 --> 00:16:42,960
En cambio, un trigger, quiero que cada modificación de precio quede registrada automáticamente, eso encajaría dentro de un trigger. No compiten entre sí, sino que se complementan. De hecho, como hemos visto, en el caso práctico, un trigger puede activarse y delegar parte del trabajo a un procedimiento almacenado.

150
00:16:46,080 --> 00:16:56,639
Como conclusión general, decir que la automatización en una base de datos permite que el motor no solo almacene información, sino que también participe activamente en el procesamiento.

151
00:16:56,639 --> 00:17:09,920
Los procedimientos almacenados sirven para encapsular lógica reutilizable que se invoca de forma explícita, mientras que los triggers permiten reaccionar automáticamente a cambios en las tablas.

152
00:17:09,920 --> 00:17:19,619
Juntos forman una herramienta muy potente para validar datos, reducir duplicidad, mejorar la consistencia y automatizar tareas críticas.