Curso de MySQL

Consultas INSERT, UPDATE y DELETE en MySQL: caso práctico

Por Víctor Peña · Publicado el

Consultas INSERT, UPDATE y DELETE en MySQL

Hola, ¿cómo están? Continuando con el curso de MySQL, hoy juntamos las tres sentencias de manipulación de datos en un caso práctico completo.

Ya vimos INSERT y UPDATE y DELETE por separado. Esta lección es sobre cómo se combinan en operaciones reales, que es donde aparecen los problemas interesantes.

¡Empecemos!

Las tres sentencias, en contexto

Se las conoce como sentencias DML (Data Manipulation Language), frente a las DDL como CREATE TABLE que definen la estructura.

Sentencia Qué hace Riesgo
INSERT Agrega registros Bajo
UPDATE Modifica registros Alto sin WHERE
DELETE Elimina registros Alto sin WHERE

La asimetría es clara: un INSERT mal hecho se corrige borrando la fila. Un UPDATE sin WHERE sobre una tabla de cien mil registros requiere restaurar un respaldo.

Transacciones: cuando varias operaciones son una sola

Este es el concepto central de la lección.

Imagina que un paciente reprograma su cita: hay que cancelar la anterior y crear la nueva. Si el sistema falla entre las dos operaciones, el paciente se queda sin ninguna cita.

START TRANSACTION;

UPDATE citas
SET estado = 'cancelada'
WHERE id = 2;

INSERT INTO citas (paciente_id, doctor_id, fecha, hora, costo)
VALUES (1, 1, '2026-05-05', '10:00:00', 250.00);

COMMIT;

Con la transacción, o se completan las dos o no se completa ninguna. No hay estado intermedio posible.

Y si algo sale mal:

ROLLBACK;

Todo vuelve a como estaba antes del START TRANSACTION.

Las propiedades ACID

Esto es lo que garantiza una transacción, y es la razón por la que existen las bases de datos relacionales:

  • Atomicidad — todo o nada.
  • Consistencia — los datos quedan válidos, respetando las restricciones.
  • Aislamiento — las transacciones no se interfieren entre sí.
  • Durabilidad — una vez confirmado, sobrevive a un corte de energía.

Requiere InnoDB. MyISAM no soporta transacciones, que es otro motivo más para no usarlo.

Caso práctico: atender una cita

Vamos con una operación completa del sistema. Cuando un doctor atiende a un paciente hay que registrar el diagnóstico, marcar la cita como atendida y dejar constancia.

START TRANSACTION;

UPDATE citas
SET estado = 'atendida',
    diagnostico = 'Control rutinario sin novedades. Presión arterial normal.'
WHERE id = 5;

INSERT INTO citas (paciente_id, doctor_id, fecha, hora, costo, estado)
VALUES (3, 4, '2026-05-25', '15:00:00', 200.00, 'programada');

-- Revisar antes de confirmar
SELECT id, estado, fecha FROM citas WHERE paciente_id = 3;

COMMIT;

Ese SELECT intermedio es un hábito que vale oro: ves el resultado antes de que sea definitivo, y si algo no cuadra, ROLLBACK.

Actualizar usando datos de otra tabla

Una operación que aparece constantemente y que mucha gente resuelve con un bucle en la aplicación:

-- Subir un 15 % el costo de las citas de cardiología
UPDATE citas c
JOIN doctores d ON c.doctor_id = d.id
JOIN especialidades e ON d.especialidad_id = e.id
SET c.costo = c.costo * 1.15
WHERE e.nombre = 'Cardiología'
  AND c.estado = 'programada';

Un UPDATE con JOIN hace en una sentencia lo que en la aplicación serían cientos de consultas. Veremos los JOIN en detalle más adelante, pero ya puedes intuir la potencia.

Y con DELETE funciona igual:

DELETE c FROM citas c
JOIN pacientes p ON c.paciente_id = p.id
WHERE p.cedula = '4567890'
  AND c.estado = 'cancelada';

Fíjate en el DELETE c: hay que indicar de qué tabla se borra, porque en la sentencia hay dos.

Insertar a partir de una consulta

Archivar registros antiguos, moviéndolos a otra tabla:

START TRANSACTION;

-- 1. Copiar a la tabla de archivo
INSERT INTO citas_archivo
SELECT * FROM citas
WHERE fecha < '2025-01-01';

-- 2. Verificar que se copiaron
SELECT COUNT(*) FROM citas_archivo;

-- 3. Eliminar de la tabla principal
DELETE FROM citas WHERE fecha < '2025-01-01';

COMMIT;

Aquí la transacción es imprescindible: si el DELETE se ejecutara sin que el INSERT hubiera funcionado, perderías los datos.

Operaciones por lotes

Cuando hay que modificar millones de filas, hacerlo de una vez bloquea la tabla y deja el sistema inaccesible. La solución es trocear:

-- Repetir hasta que afecte 0 filas
DELETE FROM citas
WHERE estado = 'cancelada'
  AND fecha < '2024-01-01'
LIMIT 1000;

Cada ejecución borra mil filas y libera el bloqueo. En producción esto se automatiza con un script que repite hasta terminar.

Puntos de guardado

En transacciones largas puedes marcar puntos intermedios:

START TRANSACTION;

INSERT INTO especialidades (nombre) VALUES ('Neurología');
SAVEPOINT especialidad_creada;

INSERT INTO doctores (matricula, nombre, apellido, especialidad_id)
VALUES ('MED-005', 'Sofía', 'Blanco', LAST_INSERT_ID());

-- Si esto último falla, vuelve solo hasta el punto marcado
ROLLBACK TO especialidad_creada;

COMMIT;

Se usa poco, pero conviene saber que existe.

Ejercicio propuesto

Con los datos de prueba que insertamos, intenta resolver esto:

  1. Registrar un paciente nuevo y agendarle una cita con el doctor de pediatría, en una sola transacción.
  2. Cancelar todas las citas programadas con fecha anterior a hoy.
  3. Subir un 10 % el costo de las citas de traumatología que aún no se atendieron.
  4. Archivar y eliminar las citas canceladas de más de un año.

Antes de cada UPDATE o DELETE, escribe primero el SELECT equivalente y comprueba las filas.

Buenas prácticas, resumidas

Siempre:

  • SELECT de prueba antes de modificar o borrar.
  • WHERE en todo UPDATE y DELETE.
  • Transacción cuando la operación involucra más de una sentencia.
  • Revisar el número de filas afectadas.
  • Nombres de columna explícitos en el INSERT.

Nunca:

  • Ejecutar en producción sin respaldo reciente.
  • Concatenar datos del usuario en la sentencia. Recuerda las consultas preparadas.
  • Desactivar el modo seguro por costumbre.
  • Modificar millones de filas de una sola vez.

Para cerrar

Con INSERT, UPDATE y DELETE ya puedes construir la parte de escritura de cualquier sistema. Lo que separa el código profesional del improvisado no es la sintaxis, que es sencilla: es usar transacciones cuando corresponde y comprobar antes de confirmar.

Hasta aquí hemos escrito datos. En la siguiente lección empezamos a leerlos, que es donde MySQL despliega de verdad su potencia.

Saludos y éxitos.

Norvic Software

Desarrollamos el software que tu empresa necesita

Somos una fábrica de software en Bolivia. Construimos sistemas a medida y aplicaciones móviles, y llevamos Inteligencia Artificial a las empresas que ya tienen un sistema funcionando.

Solicitar cotizaciónVer todos los servicios

Cotización sin costo · Respuesta directa por WhatsApp