Respuesta.

Las tablas relacionadas (por ejemplo, "pedidos" y "clientes") han existido en bases de datos relacionales desde el principio, pero en las primeras etapas, el control de integridad tenía que implementarse manualmente a través de la lógica del programa. Con el desarrollo de SQL, surgieron restricciones integradas (FOREIGN KEY) y acciones automáticas (CASCADE).

Historia del problema:

Inicialmente, las bases de datos requerían mecanismos para mantener la integridad, para evitar registros "huérfanos" (por ejemplo, un pedido sin un cliente existente). FOREIGN KEY se convirtió en un estándar y las opciones CASCADE automatizaron la sincronización al eliminar y modificar registros.

Problema:

Sin acciones en cascada, la eliminación o actualización de una fila en la tabla principal puede llevar a errores o datos "huérfanos". Delegar esta tarea en la aplicación a menudo conlleva una complejidad de mantenimiento y el riesgo de incidentes en operaciones masivas. Un uso incorrecto de las acciones en cascada puede causar eliminaciones en cadena o violar la lógica del negocio.

Solución:

El uso de FOREIGN KEY con ON DELETE CASCADE y ON UPDATE CASCADE permite mantener automáticamente la integridad y sincronizar correctamente las tablas relacionadas. En escenarios complejos (por ejemplo, si se requiere no solo eliminar sino también registrar acciones) se utilizan desencadenadores.

Ejemplo de código:

CREATE TABLE Customers (
  CustomerID INT PRIMARY KEY,
  Name NVARCHAR(100)
);

CREATE TABLE Orders (
  OrderID INT PRIMARY KEY,
  CustomerID INT,
  Amount DECIMAL(10,2),
  FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
    ON DELETE CASCADE
    ON UPDATE CASCADE
);

Características clave:

ON DELETE CASCADE: eliminación automática de registros hijos al eliminar el padre.
ON UPDATE CASCADE: actualización automática del valor de la clave externa.
En escenarios complejos, se puede implementar a través de desencadenadores para acciones personalizadas.

Preguntas capciosas.

¿La eliminación en cascada siempre es la mejor práctica para todas las relaciones?

No: para datos "históricos" o información de archivo, la eliminación en cascada puede resultar en la pérdida de información valiosa. Es importante entender el valor comercial de cada tipo de relación.

¿Funciona ON UPDATE CASCADE si la clave externa no forma parte de la PRIMARY KEY de la tabla padre?

En la mayoría de los SGBD, la clave externa debe referenciar una PRIMARY KEY o una clave única para soportar cascadas. De lo contrario, el comando no funcionará.

¿Puede una cadena de cascada exceder los límites permitidos de nivel de anidación (recursión), y qué sucederá?

Sí: con grandes cascadas, es posible exceder el límite de profundidad (por ejemplo, en SQL Server — 32). Esto provocará un error y revertirá la operación.

Errores comunes y anti-patrones

Eliminación en cascada con un control débil: una posible pérdida de datos importantes.
Ignorar la necesidad de registrar cambios masivos.
Construcción de desencadenadores sin considerar el rendimiento (por ejemplo, introducir una recursión infinita).

Ejemplo del mundo real

Caso negativo

En el sistema de gestión de proveedores y pedidos se aplicó ON DELETE CASCADE — los clientes eliminaron accidentalmente un proveedor importante, y se eliminaron automáticamente todos los pedidos, perdiéndose la historia de suministros. Fue imposible recuperar los datos.

Ventajas:

Mínimo trabajo manual.

Desventajas:

Pérdida de la historia comercial.

Caso positivo

Se utilizó ON DELETE SET NULL, más un desencadenador para el registro — incluso después de eliminar el registro del cliente, la historia de pedidos se mantenía (se asignaba un estado de no actualizados), evitando eliminaciones masivas accidentales.