Activa JavaScript para disfrutar de los vídeos de la Mediateca.
Procedimientos almacenados y triggers. Vídeo 1 - Contenido educativo
Ajuste de pantallaEl ajuste de pantalla se aprecia al ver el vídeo en pantalla completa. Elige la presentación que más te guste:
Procedimientos almacenados y triggers. Vídeo 1
Buenos días a todos. Voy a hacer dos vídeos para introducir un poquito o explicar algunos
00:00:00
aspectos de esta unidad. En esta portada introduce el tema general, cómo hacer que una base
00:00:13
de datos no solo almacene información, sino que además ejecute la lógica de manera automática.
00:00:19
La idea principal es que muchas veces pensamos que la base de datos solo guarda datos y que toda la inteligencia está en la aplicación, pero aquí se plantea otra visión.
00:00:25
Parte de esa inteligencia puede vivir dentro del propio motor de la base de datos usando dos herramientas principales que serían los procedimientos almacenados y los disparadores o los llamados triggers.
00:00:38
En esta presentación voy a explicar cómo una base de datos puede hacer mucho más que guardar datos.
00:00:50
Puede calcular, validar, automatizar tareas y reaccionar ante cambios sin que la aplicación tenga que controlar todo manualmente.
00:00:56
Para ello se usan dos mecanismos muy importantes que son los procedimientos almacenados y los disparadores.
00:01:06
Las ideas básicas que hay que remarcar serían automatizar una base de datos, que significaría mover parte de la lógica al servidor SQL. Eso puede mejorar la organización, la reutilización y, en algunos casos, el rendimiento.
00:01:12
Y no se trata de sustituir totalmente a la aplicación, sino de repartir responsabilidades de forma inteligente. Por ejemplo, en una tienda online, cuando se registra una venta, la base de datos podría calcular automáticamente una comisión, actualizar un stock o registrar una auditoría sin que el programador tenga que repetir esa lógica en cada pantalla o módulo.
00:01:28
Bueno, el paradigma de la lógica interna vemos aquí a la izquierda la lógica en la aplicación, en el que la aplicación vemos que es compleja.
00:01:49
La base de datos actúa como almacenamiento simple y toda la carga de procesamiento recae en la aplicación.
00:02:03
Hay más tráfico entre cliente y servidor.
00:02:09
A la derecha vemos la lógica en la base de datos.
00:02:11
La aplicación es más ligera, la base de datos es inteligente, los procedimientos almacenados viven dentro del motor
00:02:14
y se pueden cambiar ciertas reglas sin modificar tanto la aplicación principal.
00:02:20
Por lo tanto, en el primer modelo la aplicación hace cálculos, valida, transforma datos,
00:02:27
construye consultas complejas y luego usa la base de datos solo como un almacén.
00:02:34
Mientras que en el segundo modelo parte de esa lógica se traslada al servidor,
00:02:38
la aplicación llama a rutinas ya preparadas y la base de datos las procesa directamente.
00:02:42
Entonces, esta diapositiva enfrenta dos filosofías. En la primera, toda la inteligencia en la aplicación está en la aplicación y la base de datos solo guarda datos. Y en la segunda parte de esa inteligencia se mueve el motor de la base de datos mediante procedimientos almacenados.
00:02:47
El resultado es una aplicación más ligera y una base de datos capaz de ejecutar su lógica propia.
00:03:03
Ventaja, el primer enfoque, la lógica está centralizada en el código de la aplicación,
00:03:12
a veces más difícil de versionar para equipos de desarrollo.
00:03:17
Y la segunda, tenemos que es un enfoque que se reduce en la duplicidad
00:03:21
y se encapsulan reglas importantes cerca de los datos.
00:03:25
Imaginemos una empresa con tres aplicaciones distintas,
00:03:28
una web, una aplicación móvil y un sistema interno.
00:03:30
Si las tres tienen que calcular el mismo descuento y lo hacen cada una por su cuenta, puede haber errores o inconsistencias. Si ese cálculo está en un procedimiento almacenado, las tres aplicaciones usan exactamente la misma lógica.
00:03:33
Entonces, mover la lógica al motor permite desacoplar parte del procedimiento de la capa cliente y acercarlo al dato, que es donde realmente ocurre la operación.
00:03:46
Aquí descomponemos lo que es un procedimiento almacenado en el que aparecen las distintas partes del mismo.
00:03:58
En la primera tenemos la declaración de la rutina, que sería esta de aquí, en el que se comienza con Create, Procedure y luego el nombre del procedimiento.
00:04:09
Este va a llevar parámetros de entrada y salida.
00:04:21
Veis que aquí los paréntesis sí tienen que aparecer, pero que los parámetros, al ponerlos entre corchetes, serían parámetros en el que son opcionales.
00:04:25
Entonces, aquí entrarían las variables de entrada y las variables de salida, como si fuera un método, una función o un procedimiento.
00:04:36
Bueno, aquí sería un procedimiento en este caso.
00:04:43
También tiene una serie de características que también son opcionales, en el que vemos el comportamiento determinista, veremos más adelante qué es.
00:04:46
y luego el cuerpo de la rutina, que es donde están las sentencias SQL válidas.
00:04:53
Además, aquí nos aparece el requisito de qué versión de MySQL necesitamos para que esto funcione.
00:04:59
Pero un procedimiento almacenado es una rutina guardada dentro de la base de datos que contiene instrucciones SQL
00:05:07
y que luego puede invocarse por un nombre, como una llamada a una función o un procedimiento.
00:05:12
Es como una función o bloque de instrucciones reutilizable, pero almacenado en el servidor de la base de datos.
00:05:17
Aquí vemos la estructura general de un procedimiento almacenado. Primero se declara el nombre, después se definen sus parámetros, si los tiene, luego pueden indicarse ciertas características de comportamiento y finalmente se escribe el bloque de instrucciones SQL que ejecutará, en otras palabras, es una rutina que queda guardada en la base de datos y que puede reutilizarse todas las veces que se haga falta.
00:05:22
El nombre del procedimiento identifica la rutina, convierte que sea descriptivo
00:05:43
Por ejemplo, podemos llamarle calcular comisión, insertar cliente, obtener facturas pendientes, etc.
00:05:51
Los parámetros permiten enviar datos al procedimiento o recibir resultados
00:05:56
Y características sirven para describir propiedades de la rutina
00:06:00
En una explicación oral no hace falta profundizar demasiado aquí
00:06:04
pero sí decir que algunas opciones especifican cómo se comporta o qué tipo de operaciones va a realizar.
00:06:08
El cuerpo es la lógica real, es donde están las consultas, validaciones, asignaciones, condiciones, etc.
00:06:15
Un ejemplo sencillo, por ejemplo, sería un procedimiento llamado obtener empleados por departamento,
00:06:20
en el que recibe el ID de un departamento y devuelve todos los empleadores de ese departamento.
00:06:26
En vez de escribir siempre la misma consulta, desde la aplicación se centraliza en la base de datos.
00:06:30
Un ejemplo sería, pues, create procedure, listar productos, abre paréntesis, cierra paréntesis, y luego dentro del mismo procedimiento aparecerían todas las instrucciones SQL. Por ejemplo, select asterisco from productos. Es un ejemplo simple, pero nos da una idea de que podemos guardar una consulta bajo un nombre y luego reutilizarla cuando queramos.
00:06:36
En cuanto a la comparación de procedimientos, aquí tenemos sin procedimientos almacenados y con procedimientos almacenados para que veáis la diferencia
00:06:57
Sin procedimiento almacenado que tenemos muchas secuencias, muchas sentencias SQL complejas que viajan entre la aplicación y el servidor
00:07:10
Se satura más la red, hay más ida y vuelta de instrucciones, mientras que en el procedimiento almacenado que tenemos aquí abajo
00:07:17
Solo se envía una llamada breve con la llamada con call, se llamaría al procedimiento y le llama por su nombre, con nombre guión bajo SP entre paréntesis. ¿Por qué? Porque no tiene ningún parámetro de entrada. El procesamiento, recordad que siempre los paréntesis hay que ponerlos por defecto.
00:07:23
El procesamiento ocurre en el servidor y se minimiza, lógicamente veis, el tráfico. La adquisitiva destaca que los procedimientos almacenados pueden reducir el tráfico de red porque en vez de mandar grandes consultas o múltiples operaciones desde la aplicación, solo se manda una orden corta para que el servidor haga el resto.
00:07:41
Se observa una ventaja importante, la reducción del tráfico de red. Si la aplicación necesita ejecutar muchas sentencias complejas, cada una de ellas tiene que enviarse al servidor. En cambio, con procedimientos almacenados basta con mandar una llamada corta y dejar que el motor realice internamente todo el trabajo.
00:08:00
No siempre es mejor el rendimiento, será enorme en todos los casos
00:08:16
pero sí hay ventajas claras cuando tenemos que hay muchas operaciones encadenadas
00:08:25
la lógica es repetitiva o el sistema trabaja con muchas peticiones
00:08:30
Pensemos en un cierre mensual sin procedimientos almacenados
00:08:34
la aplicación podría enviar una consulta para ventas, otra para comisiones
00:08:39
y otra para actualizar estados y otra para auditoría
00:08:42
Con un procedimiento almacenado, todo eso puede quedar dentro de una sola rutina y la aplicación solo ejecutará el call, cierre mensual, entre paréntesis, punto y coma.
00:08:45
¿Veis la diferencia y la sencillez con el hecho de tener un procedimiento almacenado?
00:08:58
Hablamos de los parámetros. Aquí se explican los tres tipos de parámetros que puede haber.
00:09:11
El IN será valores de entrada que ingresan para ser procesados. El OUT será, veis aquí que ha llamado al procedimiento P2 metiendo un parámetro que es este número entero. El OUT sería el resultado que devuelve el procedimiento. Variables que ya no solo, ahora ya no entra un parámetro sino que va a devolver un parámetro y se devuelve a través de esta arroba Y.
00:09:14
Esto va a hacer que luego se devuelva en esta otra a través del select. En cuanto al in-out es cuando entra con un común valor y lo modifica y sale cambiado. Como tanto, el in sirve para pasar datos al procedimiento. El procedimiento los usa, pero no los devuelve modificados como salida formal.
00:09:39
Es el call que tenemos aquí.
00:10:02
Aquí 1, 2, 3, 4, 5 entra para ser procesado.
00:10:04
En cambio, en el out sirve para devolver un resultado al exterior.
00:10:08
La aplicación o la sesión SQL recibe el valor generado, que sería este de aquí.
00:10:10
Y una vez que lo recibe, tenemos que lo devuelve.
00:10:19
Aquí lo ha utilizado y con él se le devuelve menos 5.
00:10:23
El último sería el in-out, que sería el parámetro que llega con un valor inicial y luego se devuelve, se transforma y lo devuelve de nuevo.
00:10:27
Los parámetros son la forma en la que un procedimiento se comunica con el exterior.
00:10:35
Los parámetros in introducen datos, los out devuelven resultados y los in-out hacen que las dos cosas se produzcan a la vez,
00:10:39
porque reciben un valor, lo procesan y luego lo devuelven modificado.
00:10:45
Un ejemplo de IN, si tengo un procedimiento llamado buscar cliente, por ejemplo, en el que dentro del mismo hemos metido el ID cliente como un valor entero, se pondría como IN de ser un valor que se va a ingresar, ID cliente es el nombre del parámetro y luego IN que sería el tipo de, eso aparecería entre paréntesis en el procedimiento.
00:10:49
El identificador del cliente entra al procedimiento para localizar sus datos. En el out, si tengo, por ejemplo, contar pedidos, podemos poner dentro de entre paréntesis out total in, que sería out porque es un parámetro de salida, por total sería el nombre del parámetro e in sería porque es un entero.
00:11:11
El procedimiento calcula el número de pedidos y lo guarda en una variable de salida.
00:11:29
Y el in-out, supongamos un procedimiento que recibe un saldo provisional y le añade un bonus.
00:11:35
Entonces el valor entra con una cantidad inicial y sale con otra distinta.
00:11:40
Podemos imaginarlo como una caja.
00:11:44
In mete información dentro, out saca información fuera e in-out mete algo, lo transforma dentro y lo devuelve.
00:11:46
Por tanto, los pasos en la construcción y ejecución de lo que estamos hablando serían estos cuatro.
00:11:55
En un principio preparamos, creamos y seleccionamos la base de datos. Después la estructura en la que creamos una tabla e insertamos datos dentro de la misma. El paso tercero sería la declaración del procedimiento. Hemos creado el procedimiento llamado P1 sin parámetros ni de entrada ni de salida ni de entrada a salida y las sentencias SQL lo único que hace es un select desde la tabla D.
00:12:00
Por último, llamamos para ejecutar dicho procedimiento almacenado a través de call,
00:12:23
llamando al nombre de la función sin parámetros y nos devolvería esto que aparece aquí.
00:12:28
Esta diapositiva no se centra solo en la sintaxis, sino en el flujo mental correcto al trabajar con procedimientos.
00:12:34
Primero preparo el entorno, luego creo la estructura de datos, después defino la rutina y por último la ejecuto.
00:12:40
Aquí vemos que trabajar con procedimientos no consiste solo en escribir un create procedure.
00:12:46
dure. Antes hay que preparar el contexto, seleccionar la base de datos correcta, crear tablas y datos de
00:12:50
ejemplo. Solo entonces se declara el procedimiento y finalmente se ejecuta con call. Un ejemplo sería
00:12:56
si quiero crear un procedimiento que devuelva todos los productos caros, antes necesito que
00:13:01
exista una tabla de productos y que tenga registros. No tendría sentido definir la rutina
00:13:07
sobre una tabla que todavía no está creada. Por tanto, este esquema refleja una metodología muy
00:13:12
útil, primero se construye el escenario, luego se define la lógica y finalmente se prueba. Es
00:13:18
parecido a programar una función, antes de usarla necesitamos que existan las variables y las
00:13:22
estructuras con las que vamos a trabajar. Aquí en esta nueva diapositiva hablamos del uso del
00:13:27
delimiter para agrupar la lógica compleja con bloques begin, end. A la izquierda aparece el
00:13:39
problema, que sería si no cambiamos el delimitador, MySQL puede interpretar el punto y coma como final
00:13:47
prematura del comando. Entonces, y el procedimiento no se crea correctamente. Aquí lo tenemos, tenemos
00:13:54
el create procedure simple proc con un parámetro dentro de la salida. ¿Veis cómo lo pone? Pone qué
00:13:59
tipo de parámetro es, in, out o in out. Aquí es uno de salida. ¿Qué nombre tiene el parámetro? Le llama
00:14:05
parámetro 1 y luego qué tipo de parámetro va a ser, que es un valor entero. Después mete el begin y aparecería al final el end. Si veis aquí, si no ponemos el proceduré
00:14:12
aquí nos está dando, aquí terminaría de manera, generaría un error porque terminaría de manera prematural no poner el delimiter. Entonces, si veis aquí a la derecha,
00:14:25
Tenemos la solución, cambiar temporalmente el delimitador, por ejemplo, con dos barras. Hemos definido el delimitador con esas dos barras para indicar que tiene que leer todo el procedimiento. El procedimiento desde que empieza hasta que finaliza para que no finaliza de manera prematura en la primera sentencia que encuentra.
00:14:39
Definir todo el procedimiento, cerrar con el end
00:14:56
y posteriormente poner el delimitador que hemos definido al principio.
00:14:58
Y luego restaurar el delimiter a punto y coma
00:15:02
para que pueda ser utilizado en las siguientes sentencias SQL.
00:15:05
El cliente MySQL normalmente entiende punto y coma como fin de instrucción,
00:15:10
pero dentro de un procedimiento queremos poner muchas sentencias
00:15:15
terminadas en punto y coma y no queremos que terminen de manera prematura,
00:15:17
como aquí generando este error.
00:15:21
Entonces, si no cambiamos el delimitador,
00:15:22
el cliente cree que la institución terminó antes de tiempo, por eso se cambia a otro símbolo temporalmente.
00:15:24
Esta es una parte muy importante de MySQL, cuando un procedimiento tiene varias sentencias dentro de un bloque,
00:15:29
veis que tiene un bloque que empieza aquí con el begin y un bloque que termina con el end.
00:15:35
Cada una suele acabar en un punto y coma, el problema es que el cliente MySQL también usa ese símbolo
00:15:40
para decidir cuándo ha terminado un comando completo, por eso cambiamos temporalmente el delimitador,
00:15:47
por ejemplo con barra a barra, podéis poner otro
00:15:52
para que todo el bloque llegue
00:15:54
entero al servidor, lea todo ese bloque
00:15:57
...
00:15:59
- Idioma/s:
- Materias:
- Informática
- Niveles educativos:
- ▼ Mostrar / ocultar niveles
- Formación Profesional
- Ciclo formativo de grado superior
- Primer Curso
- Segundo Curso
- Autor/es:
- Francisco José González Constanza
- Subido por:
- Francisco J. G.
- Licencia:
- Todos los derechos reservados
- Visualizaciones:
- 4
- Fecha:
- 6 de abril de 2026 - 11:20
- Visibilidad:
- Público
- Centro:
- IES CIFP a Distancia Ignacio Ellacuría
- Duración:
- 16′ 04″
- Relación de aspecto:
- 1.78:1
- Resolución:
- 1920x1080 píxeles
- Tamaño:
- 77.25 MBytes
