Recommended Free Tools
ON DELETE CASCADE elimina automáticamente las filas hijas que hacen referencia a una fila padre eliminada. Es adecuado cuando el hijo realmente forma parte del padre —por ejemplo, las líneas de un pedido—, pero puede salir caro si el borrado del padre alcanza datos que debían conservarse o desencadena una operación mayor de lo esperado. No es inherentemente lento: el coste depende del diseño, los datos, la carga y el motor de base de datos.
Qué borra realmente ON DELETE CASCADE
La acción pertenece a una clave foránea. Cuando se elimina una fila de la tabla referenciada (el padre), el motor elimina las filas de la tabla que contiene la clave foránea (las hijas) y que apuntan a ese padre.
As an Amazon Associate I earn from qualifying purchases.
CREATE TABLE orders (
id bigint PRIMARY KEY
);
CREATE TABLE order_items (
id bigint PRIMARY KEY,
order_id bigint NOT NULL
REFERENCES orders(id)
ON DELETE CASCADE
);Si se elimina un registro de orders, también se eliminan sus filas correspondientes en order_items. Esa eliminación de las líneas no aparece como una segunda instrucción en la sentencia que ejecuta la aplicación: es una consecuencia de la regla de integridad referencial. PostgreSQL describe esta acción y recomienda escogerla según la relación entre las entidades (documentación de PostgreSQL 16 sobre restricciones).
Cuándo la cascada refleja el modelo de datos
Úsala cuando el hijo dependa del padre para existir
Una línea de pedido suele ser parte del pedido, no una entidad que tenga sentido conservar por separado tras borrar ese pedido. En ese caso, eliminar automáticamente sus líneas puede representar con precisión la composición entre ambas tablas y evitar dejar registros huérfanos.
#1 Best Overall
Evítala cuando ambas filas representen entidades independientes
Un producto y un pedido tienen ciclos de vida distintos. Borrar un producto no debería eliminar silenciosamente pedidos históricos que lo referencian. Para ese tipo de vínculo, PostgreSQL propone considerar RESTRICT o NO ACTION, en lugar de tratar la entidad relacionada como propiedad del padre (véase la guía de restricciones de PostgreSQL 16).
La pregunta de diseño es, por tanto, semántica: ¿el hijo es un componente que no puede existir sin su padre, o es una entidad independiente cuya referencia debe protegerse o gestionarse de otra manera?
Por qué puede costar caro
El alcance de la sentencia puede quedar oculto
Una instrucción dirigida a una sola fila padre puede eliminar muchas filas dependientes, incluso en otras tablas enlazadas mediante claves foráneas con cascada. El riesgo no es que toda cascada sea lenta, sino que el alcance real resulte más amplio de lo que quien ejecutó la instrucción recuerda o pretendía. Esa consecuencia se deriva del comportamiento de la regla; no hay una estadística general que permita estimar cuántas filas eliminará una cascada típica o con qué frecuencia causa incidentes.
Free tools Windows power users keep installed
One-click scans. No signup required.
El trabajo resultante depende del motor y del caso concreto
Eliminar filas relacionadas también puede implicar trabajo de integridad referencial, bloqueos y actividad de triggers. La documentación de InnoDB, por ejemplo, indica que las comprobaciones de claves foráneas toman bloqueos compartidos sobre las filas que deben examinar (manual de MySQL 8.4 sobre claves foráneas). SQL Server documenta acciones referenciales en tablas relacionadas y un orden definido para la participación de triggers (documentación de SQL Server sobre restricciones). Son detalles de implementación, no una comparación que demuestre que un motor o una cascada sean siempre más lentos.
Sin una prueba sobre un esquema, un volumen de datos y un motor concretos, no se puede atribuir a ON DELETE CASCADE una cifra universal de coste o degradación.
Alternativas según lo que deba ocurrir con el hijo
| Acción | Resultado al borrar el padre | Cuándo encaja |
|---|---|---|
CASCADE |
Elimina automáticamente las filas hijas referenciadas. | El hijo es un componente que no debe sobrevivir al padre, como una línea perteneciente a un pedido. |
RESTRICT |
Impide borrar el padre mientras existan filas relacionadas. | La relación debe protegerse y el borrado de dependencias requiere una decisión explícita. |
NO ACTION |
La operación no puede dejar una referencia inválida; según el motor y las restricciones aplicables, el borrado puede rechazarse. | Se quiere preservar la integridad referencial sin borrar hijos automáticamente. |
SET NULL |
Conserva las filas hijas y establece en NULL la columna de la clave foránea. |
El vínculo es opcional y la columna admite NULL. |
SET DEFAULT |
Conserva las filas hijas y establece el valor predeterminado de la columna. | El valor predeterminado es válido para la restricción de clave foránea y el diseño lo permite. |
Las opciones disponibles y sus condiciones precisas dependen del motor. PostgreSQL documenta las condiciones de SET NULL y SET DEFAULT en su documentación de restricciones de la versión 18. No basta con escoger una acción por su nombre: columnas, valores predeterminados y demás restricciones también deben admitir el resultado.
Cómo decidir antes de añadir una cascada
- Define la relación: determina si la fila hija es un componente del padre o una entidad con vida propia.
- Decide la política de retención: aclara si el hijo debe desaparecer, sobrevivir sin referencia o impedir que se borre el padre.
- Revisa el alcance indirecto: sigue las claves foráneas que pueden propagar el borrado a otras tablas y comprueba qué datos podrían desaparecer.
- Valida las reglas del motor usado: comprueba su documentación para la versión desplegada, incluidas las interacciones con restricciones y triggers.
- Ensaya operaciones amplias en condiciones representativas: si el volumen o la actividad concurrente importan, mide en el motor y el esquema reales; no deduzcas el rendimiento de la palabra
CASCADE. - Prepara recuperación adecuada: una cascada no sustituye una política de copias de seguridad y restauración. AWS describe opciones de backup para PostgreSQL y la retención y restauración de Aurora en sus orientaciones para PostgreSQL y documentación de backups de Aurora.
ON DELETE CASCADE no es DROP … CASCADE
ON DELETE CASCADE elimina filas de tablas relacionadas al borrar una fila padre. En cambio, PostgreSQL usa DROP ... CASCADE para eliminar objetos de esquema que dependen del objeto que se está quitando; entre sus ejemplos está una restricción de clave foránea dependiente. Son operaciones distintas: una afecta datos y la otra dependencias del esquema (seguimiento de dependencias en PostgreSQL).
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
