Por qué usar ON DELETE CASCADE en SQL te puede costar caro (Arquitectura de BD real)

Sergio Leal — Fri, 02 Oct 2026 19:18:51 +0000

Veo muchos tutoriales que enseñan a armar tablas relacionales usando INT AUTO_INCREMENT y borrados en cascada. En un proyecto de universidad está bien, pero en un sistema transaccional real (como un e-commerce o una app de delivery), hacer eso destruye la contabilidad o expone tus métricas de ventas a la competencia.

1. El error de los identificadores: INT vs UUID

Si usas INT AUTO_INCREMENT en una tabla de Pedidos, expones métricas de negocio. Si un competidor hace un pedido hoy y su ID es 100, y mañana hace otro y su ID es 150, sabrá exactamente cuántos pedidos procesaste.
Solución: Usa UUID para las transacciones expuestas al cliente.

2. El peligro del ON DELETE CASCADE

Muchos enseñan a usar ON DELETE CASCADE en las claves foráneas. Si borras a un usuario del sistema, el motor SQL borrará en cascada todas sus facturas y pedidos, dejando tu contabilidad descuadrada.
Solución: En tablas transaccionales se debe usar RESTRICT o SET NULL.

Armé una guía técnica profunda sobre cómo estructurar un backend desde cero, manejar precisión financiera con DECIMAL y usar restricciones lógicas para proteger la integridad de los datos sin romper el rendimiento de los índices B-Tree.

Puedes leer la guía completa con todo el código SQL y explicaciones paso a paso en mi blog:
👉 Diseño de Bases de Datos Relacionales y Optimización SQL - LogicBoard.dev

¡Cualquier feedback sobre la arquitectura que proponen en sus trabajos es bienvenido en los comentarios!

DEV Community: Sergio Leal

[Boost]