ON DUPLICATE KEY en MySQL práctico

Domina el control de duplicados en MySQL con ejemplos reales: aprende a trabajar con columnas únicas como el email, interpreta el Error 1062 y aplica de forma segura la sentencia ON DUPLICATE KEY para actualizar registros sin romper tu modelo de datos.

¿Cómo validar datos de clientes con llaves únicas?

En la base de datos se trabaja con tablas de autores y clientes. La tabla de clientes define una llave primaria (ID) y un email único por decisión de negocio. Esto garantiza que no existan dos tuplas con el mismo correo electrónico.

• Llave primaria: identificador único por defecto en cada tabla.
• Columna única (email): restricción de negocio para evitar duplicados.
• Tupla: fila de datos en la tabla.
• Campo active: indica si el cliente está activo (1) o no (0).

Consultas básicas usadas:

SELECT * FROM authors;
SELECT * FROM clients;
DESCRIBE clients;

Los datos cargados incluyen cuatro clientes con IDs 1, 2, 3 y 4, todos con email definido y el campo active en 1.

¿Qué sucede al repetir un email?

Al intentar insertar a Pedro Sánchez de nuevo, aún quitando el ID, el sistema detecta el email duplicado y devuelve el clásico error de MySQL:

• Error 1062: duplicate key en la llave email.

Este comportamiento protege la integridad de datos sin que tengas que hacer validaciones manuales adicionales.

¿Cómo preparar el insert para actualizar si hay duplicado?

La solución propuesta es usar ON DUPLICATE KEY para actualizar campos cuando la clave única ya existe. Por ejemplo, cambiar el estado activo del cliente existente con los valores del intento de inserción:

INSERT INTO clients (name, email, active)
VALUES ('Pedro Sánchez', 'correo@ejemplo.com', 0)
ON DUPLICATE KEY UPDATE active = VALUES(active);

Idea clave: si la clave ya existe, se actualiza la tupla con el nuevo valor de active. En el video se comenta que usar email para actualizar no tiene sentido; el foco está en campos como active.

¿Cómo usar ON DUPLICATE KEY sin malas prácticas?

El docente advierte sobre una opción documentada que no recomienda: IGNORE ALL. La instrucción es clara: no la uses. Ignorar errores los invisibiliza y puede llevar a comportamientos peligrosos en producción.

• Los errores deben informar y guiar decisiones.
• Ocultar errores hace más difícil mantener la calidad de datos.
• Diseña flujos que reaccionen a los errores, no que los silencien.

Patrones mostrados para actualizar al detectar duplicado:

-- Patrón recomendado
INSERT INTO clients (name, email, active)
VALUES ('Pedro Sánchez', 'correo@ejemplo.com', 0)
ON DUPLICATE KEY UPDATE active = VALUES(active);

También se comenta una variante intermedia con UPDATE SET, y se aclara que el SET sobraba en ese contexto, dejando la forma directa UPDATE active = VALUES(active) como la elección correcta en el ejemplo.

Beneficios prácticos mencionados:

• Actualizar datos de clientes sin operaciones separadas de SELECT + UPDATE.
• Integrar información de distintos proveedores priorizando campos: si está vacío, ponlo; si ya existe y es válido, consérvalo.
• Acelerar flujos de carga evitando errores por duplicados controlados.

¿Qué trucos de consola y consultas mejoran tu flujo?

Para inspeccionar un registro específico se usó SELECT con filtro por ID del cliente, y un formato de salida más legible en la terminal.

SELECT * FROM clients WHERE client_id = 4;

• Historial en terminal: usa la flecha hacia arriba para recuperar el último comando.
• Presentación columnar: termina la consulta con \G en lugar de ; para una vista vertical más clara.

Ejemplo con salida vertical:

SELECT * FROM clients WHERE client_id = 4\G

Próximo tema anunciado: un insert con selects anidados. No es el caso más estándar, pero puede ser útil si se usa con cuidado para mezclar datos y obtener IDs correctos al vuelo.

¿Te quedaste con alguna duda sobre ON DUPLICATE KEY, llaves únicas o el manejo del Error 1062? Comparte tu caso en los comentarios y afinamos la consulta juntos.