DELETE elimina filas. Es la operación más sencilla del módulo y la que exige más criterio, porque plantea una pregunta que INSERT y UPDATE no plantean: ¿de verdad hay que borrarlo?

TiendaVerde ya te dio la respuesta sin decírtelo. Sus tablas productos y proveedores tienen una columna activo. Ese booleano existe porque, en un sistema real, un producto que se ha vendido no se borra nunca: se retira del catálogo. Borrarlo destruiría el histórico de facturación, y de hecho la clave foránea lineas_pedido.producto_id → productos.id está declarada ON DELETE RESTRICT precisamente para impedirlo. Toda esa discusión —borrado lógico frente a borrado físico— tiene aquí su lección.

Antes llegaremos a lo concreto: el protocolo de seguridad reforzado, la diferencia entre DELETE y TRUNCATE, y qué ocurre exactamente al borrar una fila de la que dependen otras, demostrado con recuentos antes y después para las tres acciones ON DELETE que TiendaVerde declara.

⚠️ Aviso de seguridad

DELETE es una operación destructiva e irreversible una vez confirmada. A diferencia de UPDATE, que sustituye un valor por otro, DELETE hace desaparecer la fila entera — y, con ON DELETE CASCADE, filas de otras tablas que no has mencionado.

• Ejecuta todos los ejemplos sobre tu base de datos de prácticas (tiendaverde), nunca en producción.
• Haz una copia de seguridad previa: pg_dump -U curso_sql -d tiendaverde -f copia.sql. Para volver al estado inicial basta con relanzar tiendaverde.sql.
• Trabaja siempre dentro de BEGIN … ROLLBACK / COMMIT mientras experimentas.
• En un sistema real, un borrado sobre datos vivos debe ir revisado por otra persona, y las políticas de borrado de datos personales requieren revisión legal (apartado 9).

1. La sintaxis, y el protocolo reforzado
2. DELETE sin WHERE frente a TRUNCATE
3. Borrar una fila referenciada: RESTRICT
4. Borrar una fila referenciada: CASCADE
5. Borrar una fila referenciada: SET NULL
6. El peligro del CASCADE y la alternativa profesional
7. DELETE ... USING: borrar según otra tabla
8. RETURNING: conservar lo que borras
9. Borrado lógico frente a borrado físico
10. Datos personales y derecho de supresión
11. Recuperación tras un borrado accidental
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Solo dos piezas: qué tabla y qué filas. No hay SET, no hay valores. Toda la responsabilidad recae sobre el WHERE.

Igual que UPDATE N, el número te dice cuántas filas ha eliminado. Y aquí importa todavía más, porque no hay ningún valor nuevo que puedas inspeccionar después: si el número no es el que esperabas, ya es tarde.

El protocolo de los cinco pasos de 05-03 se aplica igual, con dos refuerzos:

El paso 3 es el nuevo, y es el que distingue un DELETE seguro de una catástrofe. Antes de borrar un pedido, mira cuántas líneas y devoluciones tiene:

Ahora ya sabes que ese DELETE 1 va a eliminar cuatro filas en tres tablas. El apartado 4 lo demuestra.

Y el flujo completo:

Sin WHERE, DELETE vacía la tabla:

Las doce reseñas, fuera. Exactamente el mismo problema que el UPDATE sin WHERE, con la misma ausencia de aviso.

Para vaciar una tabla existe una instrucción específica, TRUNCATE:

Hacen lo mismo y no se parecen en nada:

Esa última fila merece una demostración:

TRUNCATE no ejecuta las acciones ON DELETE: o vacías todo el árbol a la vez, o no vacías nada.

Y si además quieres que las secuencias vuelvan a empezar en 1:

Cuándo usar cada uno. TRUNCATE para vaciar tablas de trabajo, de staging o de pruebas, donde quieres empezar de cero y la velocidad importa. DELETE para todo lo demás, y siempre que haya un WHERE de por medio. Un DELETE FROM tabla; sin condición sobre una tabla grande es lo peor de los dos mundos: lento, con el WAL disparado y sin liberar espacio.

Aquí empieza lo interesante. Cuando la fila que borras es el "padre" de una clave foránea, el motor aplica la acción declarada en el ON DELETE. TiendaVerde declara las tres.

RESTRICT es la barrera: prohíbe borrar. La lleva lineas_pedido.producto_id, entre otras.

El producto 1 (Aceite de oliva) aparece en 5 líneas de pedido y tiene 2 reseñas:

Léelo con calma, porque es el error más frecuente del módulo:

Compáralo con el error de INSERT de 05-02: allí decía is not present in table (referenciabas algo que no existe); aquí dice is still referenced from table (algo depende de lo que quieres borrar). Las dos mitades de la integridad referencial.

Ahora un producto que sí se puede borrar. El 19 (Desodorante natural) es uno de los tres que nunca se han vendido, y no tiene reseñas:

Del catálogo de 20 quedan 19. La restricción RESTRICT no es un obstáculo: es una función. Te está diciendo "este producto tiene historia, no lo destruyas". Y el producto 19 no la tiene.

CASCADE propaga el borrado a las filas hijas. En TiendaVerde lo llevan cuatro claves foráneas: lineas_pedido.pedido_id, devoluciones.pedido_id, resenas.producto_id y resenas.cliente_id.

El pedido 6 es el caso perfecto: está cancelado, tiene 2 líneas y 1 devolución.

Y lo que cuelga del pedido 6:

Ahora el borrado:

DELETE 1. Una sola fila, dice PostgreSQL. Miremos los recuentos:

Han desaparecido cuatro filas en tres tablas, y el contador solo ha informado de una. Ahí está, en toda su crudeza, el peligro del CASCADE: DELETE N cuenta las filas que tú has borrado, no las que el motor ha borrado en cadena.

Y las cascadas pueden encadenarse. Si lineas_pedido tuviera a su vez una tabla hija con CASCADE, el borrado seguiría bajando. En un esquema grande, un solo DELETE puede propagarse por media base de datos sin que nada te lo indique.

La forma de no llevarte sorpresas es preguntar al catálogo del sistema qué claves foráneas apuntan a una tabla:

Más rápido todavía, dentro de psql, la sección Referenced by de \d pedidos:

Consejo: haz \d tabla antes de cualquier DELETE sobre una tabla que no conozcas al dedillo. La sección Referenced by te dice en cinco segundos si vas a desencadenar una cascada.

SET NULL no borra al hijo: le quita la referencia. TiendaVerde lo declara en pedidos.empleado_id, clientes.referido_por_id y empleados.jefe_id.

El comercial Óscar Peris Blasco (empleado 4) deja la empresa. Tiene 4 pedidos asignados:

Los 20 pedidos siguen ahí. Lo que ha cambiado es que los cuatro de Óscar ahora tienen empleado_id a NULL: de 10 pedidos sin comercial hemos pasado a 14.

Y aquí hay una lección de 04-03 que conviene subrayar. Antes, empleado_id IS NULL significaba inequívocamente "pedido entrado por la web". Ahora significa dos cosas distintas: "pedido web" o "el comercial que lo gestionó ya no está en la empresa". El NULL ha perdido precisión semántica sin que nadie lo haya decidido. Es un efecto secundario clásico de SET NULL, y la razón de que muchos equipos prefieran conservar al empleado con una marca de baja en lugar de borrarlo.

Un caso más vistoso: borrar a Andrés Company Talens (empleado 2), Responsable de ventas, que no gestiona ningún pedido pero tiene tres subordinados.

Tres empleados se han quedado sin jefe, y el organigrama que 01-06 dibujaba con tanta pulcritud tiene ahora cuatro raíces en lugar de una. La empresa no se ha reorganizado: simplemente ha desaparecido un nodo intermedio del árbol y SET NULL ha hecho lo único que sabe hacer.

CASCADE es cómodo. Un DELETE y todo el árbol desaparece limpiamente, sin filas huérfanas. Y precisamente por eso es peligroso:

Por eso muchos equipos adoptan una política más conservadora: RESTRICT en todas las FK, y borrado explícito en el orden correcto, dentro de una transacción.

Compara las dos salidas. Con CASCADE: DELETE 1, y cuatro filas fuera. Explícitamente: DELETE 1, DELETE 2, DELETE 1 — cuatro filas, y las ves todas. Escribes tres líneas en lugar de una y ganas visibilidad completa sobre lo que estás destruyendo. En un sistema con datos reales, ese cambio vale mucho más de lo que cuesta.

TiendaVerde usa CASCADE en cuatro sitios y los cuatro son composición real: una línea de pedido, una devolución y una reseña no significan nada sin su padre. Es el uso correcto. La regla de 01-05 sigue vigente: pregúntate si la fila hija tiene sentido por sí sola, y si dudas, RESTRICT.

Igual que UPDATE tiene FROM, DELETE tiene USING: permite decidir qué borrar en función de otra tabla.

Depuración del catálogo: eliminar las líneas de los pedidos cancelados.

Reglas de USING, todas heredadas de UPDATE ... FROM:

• Puedes poner varias tablas, separadas por comas o con JOIN.
• La tabla destino no se repite en el USING. Si lo haces, producto cartesiano silencioso.
• Al contrario que en UPDATE ... FROM, un emparejamiento 1:N no es un problema aquí: una fila que empareja con tres se borra una sola vez. DELETE es idempotente por naturaleza.

Nota de dialecto: USING es de PostgreSQL. MySQL escribe DELETE lp FROM lineas_pedido lp JOIN pedidos pe ON ... WHERE ... (fíjate en el alias repetido tras DELETE). SQL Server usa DELETE d FROM destino d JOIN otra o ON .... Oracle no tiene ninguna de las dos y obliga a una subconsulta correlacionada. La forma portable es siempre una subconsulta: DELETE FROM lineas_pedido WHERE pedido_id IN (SELECT id FROM pedidos WHERE estado = 'cancelado') — módulo 7.

En DELETE, RETURNING devuelve las filas tal como eran justo antes de desaparecer. Es la única forma de verlas sin haberlas consultado antes.

Pero verlas no es conservarlas. Para eso, el patrón profesional combina INSERT ... SELECT (05-02) con el DELETE, dentro de una transacción:

Dentro de una transacción, o pasan las tres cosas o no pasa ninguna: es imposible que borres sin haber archivado. Fíjate en un detalle del DDL de la tabla de archivo: no lleva claves foráneas. Si las llevara, no podrías archivar una devolución cuyo pedido también se va a borrar. Las tablas de archivo son deliberadamente laxas.

RETURNING completa la trilogía: INSERT ... RETURNING te da el id generado, UPDATE ... RETURNING el valor nuevo, DELETE ... RETURNING la fila que se va. En los tres casos evita un SELECT adicional y la condición de carrera que lleva asociada.

Y llegamos al fondo del asunto.

• Borrado físico: DELETE FROM productos WHERE id = 13. La fila desaparece.
• Borrado lógico: UPDATE productos SET activo = FALSE WHERE id = 13. La fila sigue ahí, marcada como no vigente.

productos.activo y proveedores.activo son exactamente eso. No son un capricho del diseño: son la decisión, tomada en 01-05 y ahora explicada, de que en TiendaVerde nada que haya participado en una operación comercial se borra jamás.

EcoNordic Supplies está inactivo y conserva sus cuatro productos en catálogo (10, 13, 18 y 20). Con un borrado físico, o bien la FK RESTRICT habría impedido borrarlo, o bien habrías tenido que borrar cuatro productos que aún se venden.

Este es el inconveniente que subestima todo el mundo:

Cinco categorías, no seis. Complementos desaparece del informe porque su único producto (el 20) está inactivo. Y esa desaparición depende enteramente de que alguien se acordara de escribir WHERE p.activo. Olvidarlo una sola vez en un informe de dirección y estarás contando referencias que ya no se venden.

Ese olvido tiene solución, y es una vista:

A partir de ahí, las consultas de catálogo van contra productos_vigentes y el filtro es imposible de olvidar. Las vistas son la solución canónica al principal inconveniente del borrado lógico, y se estudian en la lección 10-01.

Y una tercera vía, cada vez más habitual: borrado lógico con fecha. En lugar de un booleano, una columna fecha_baja DATE nulable. Ocupa lo mismo, distingue "vigente" de "dado de baja" igual de bien (fecha_baja IS NULL) y además te dice cuándo ocurrió, que suele ser justo lo que preguntará alguien seis meses después. Si diseñas de cero, prefiérela al booleano.

Hay un caso donde el borrado lógico no es suficiente: los datos personales.

El Reglamento General de Protección de Datos europeo reconoce el derecho de supresión (artículo 17, el llamado "derecho al olvido"): una persona puede exigir que sus datos personales se eliminen, y marcar una fila como inactiva no es eliminarla. El nombre, el email y la ciudad siguen en la tabla, en las copias de seguridad y en los índices.

En TiendaVerde, la tabla clientes contiene datos personales: nombre, apellidos, email y ciudad. Y su diseño ya anticipa parte del problema:

Núria Bosch Ferrer (cliente 13) es uno de los tres clientes sin pedidos. Su borrado es limpio:

Pero con un cliente que sí ha comprado, el conflicto aparece de inmediato:

Ana Belmonte Roca tiene dos pedidos (el 6 y el 18), y pedidos.cliente_id es RESTRICT. Aquí chocan dos obligaciones legítimas:

La solución habitual en sistemas reales no es ni borrar ni no borrar: es anonimizar. Se conserva la fila —y con ella el pedido, la factura y los totales— pero se sustituyen los datos identificativos:

El pedido 6 sigue existiendo, la contabilidad cuadra, y el dato personal ha desaparecido. El email se construye con el id para no romper la restricción UNIQUE, y con un dominio inválido para que sea imposible enviar correo a esa dirección por accidente.

Las reseñas, en cambio, sí se borran: resenas.cliente_id está declarada ON DELETE CASCADE exactamente por este motivo, como razonaste en el ejercicio 1 de 01-05. Una reseña es una opinión personal; una factura es un documento contable.

⚖️ Aviso importante

Lo anterior es una explicación técnica de patrones habituales, no asesoramiento jurídico. Los plazos de conservación, qué se considera dato personal, qué grado de anonimización es suficiente y qué excepciones aplican dependen de la legislación vigente, del sector y del caso concreto.

Antes de implantar cualquier política de borrado o anonimización de datos personales en un sistema real, consúltalo con el responsable de protección de datos o con asesoría jurídica. Un DELETE mal planteado puede incumplir el RGPD; uno bien intencionado puede incumplir la normativa contable. La seguridad, los permisos y el control de acceso a estos datos se estudian en la lección 11-03.

Ha pasado. Has confirmado un DELETE que no debías. ¿Qué opciones hay?

PITR (Point-In-Time Recovery) es la técnica que permite decir "devuélveme la base tal como estaba a las 17:42:30 de ayer". Funciona porque PostgreSQL escribe todos los cambios en un registro secuencial —el WAL, Write-Ahead Log— antes de aplicarlos a los ficheros de datos. Con una copia base y el WAL posterior se puede reconstruir cualquier instante intermedio. Es también el mecanismo que hace posibles la durabilidad y la replicación, y se estudia con el resto del modelo transaccional en el módulo 9.

La conclusión práctica, que no depende de ninguna tecnología:

No hay recuperación sin copia de seguridad. La única pregunta que importa no es "¿qué hago si borro algo por error?", sino "¿cuándo se hizo la última copia y cuándo se probó por última vez restaurarla?". Una copia que nunca se ha restaurado no es una copia: es una suposición.

Para el curso, tu red de seguridad es mucho más simple: tiendaverde.sql es idempotente, y relanzarlo te devuelve al estado inicial en dos segundos.

• Olvidar el WHERE. Vacía la tabla entera sin aviso. Mismo error emblemático que en UPDATE, con consecuencias peores.
• Fiarse del DELETE N con CASCADE. Cuenta las filas que borras tú, no las que borra el motor en cadena. DELETE 1 puede ser cuatro filas, o cuatro millones.
• No comprobar qué depende de la fila antes de borrarla. \d tabla y su sección Referenced by en cinco segundos.
• Usar TRUNCATE creyendo que es un DELETE rápido. No admite WHERE, no dispara triggers de fila, no devuelve recuento, exige otro permiso y falla si hay FK apuntando a la tabla.
• Contar con que TRUNCATE sea transaccional. En PostgreSQL sí; en MySQL no, y ahí no hay ROLLBACK posible.
• Repetir la tabla destino en el USING. Producto cartesiano silencioso, igual que en UPDATE ... FROM.
• Borrar registros con histórico comercial. Para eso está activo = FALSE. La FK RESTRICT intentará frenarte; no la esquives con CASCADE.
• Implantar borrado lógico y olvidar el WHERE activo. El informe seguirá funcionando y contará productos descatalogados. Usa una vista (módulo 10).
• Creer que activo = FALSE cumple el derecho de supresión. No lo cumple: el dato personal sigue ahí. Anonimizar o borrar, según el caso y con revisión legal.
• Confundir "no tiene hijos hoy" con "se puede borrar". El producto 19 se puede borrar hoy; mañana, en cuanto alguien lo compre, ya no.
• Consejo: SELECT * antes de cualquier DELETE. Quieres ver la fila completa que va a desaparecer, no solo su id.
• Consejo: RETURNING * siempre en un DELETE. No cuesta nada y te deja constancia de lo que has borrado, aunque sea en el historial de la consola.
• Consejo: prefiere RESTRICT + borrado explícito a CASCADE. Tres líneas en lugar de una, a cambio de ver exactamente qué destruyes.
• Consejo: al diseñar, usa fecha_baja DATE en lugar de activo BOOLEAN. Cuesta lo mismo y además te dice cuándo.

Trabaja sobre la base recién recargada y usa BEGIN … ROLLBACK en todos los ejercicios.

Para cada uno de estos cinco borrados, predice el resultado antes de ejecutarlo: si funciona o falla, cuántas filas se eliminan en total y en qué tablas, y qué acción ON DELETE interviene. Después compruébalo con recuentos antes y después.

Dirección pide retirar del catálogo todos los productos del proveedor inactivo (EcoNordic Supplies, id 5).

1. Comprueba cuáles son y cuáles de ellos se han vendido alguna vez.
2. Intenta el borrado físico de todos y explica qué ocurre.
3. Propón y aplica la solución correcta, justificando por qué es la correcta.
4. Escribe la consulta de catálogo vigente que debería usar la web a partir de ahora, agrupada por proveedor.

Un compañero quiere limpiar las reseñas de productos descatalogados y te enseña esta sentencia:

1. Encuentra el error y explica qué haría realmente.
2. Escríbela correctamente y di cuántas filas borraría sobre la base recién recargada.
3. Reescríbela de forma portable, sin USING, indicando qué módulo cubre esa técnica.
4. Discute si esta limpieza es buena idea: ¿qué se pierde y qué se gana?

Solución 1

a) Falla. productos.proveedor_id es ON DELETE RESTRICT y EcoNordic tiene cuatro productos:

Que el proveedor esté activo = FALSE no cambia nada: el borrado lógico y la integridad referencial son mecanismos independientes.

b) Funciona, y borra 4 filas en 3 tablas. El pedido 10 tiene 2 líneas (ids 24 y 25) y 1 devolución (la 2, de 34,02 €), ambas con CASCADE:

Y algo que no aparece en ningún recuento: la facturación total de TiendaVerde acaba de bajar de 727,95 € a 679,68 €, porque el pedido 10 aportaba 48,27 €. Los portes bajan de 118,25 € a 105,75 €. Ningún mensaje te lo ha dicho.

c) Falla, y es el ejercicio trampa. La categoría 6 (Complementos) parece vacía porque su único producto, el 20, está descatalogado. Pero productos.categoria_id es RESTRICT y esa fila sigue existiendo:

El producto 20 está activo = FALSE, pero sigue siendo una fila de productos y la clave foránea no distingue entre activo e inactivo. El borrado lógico no libera las restricciones referenciales.

d) Funciona, 1 fila. Hugo Iglesias Pardo (cliente 14) es uno de los tres sin pedidos, no tiene reseñas y no ha referido a nadie:

clientes: 15 → 14. Ninguna cascada, ningún SET NULL. Es el único de los cinco borrados verdaderamente inocuo.

e) Funciona, y desmonta el organigrama. Rosa Alcázar Vives (empleada 1) no gestiona pedidos, pero es jefa de tres personas (2, 3 y 8), y empleados.jefe_id es SET NULL:

De 1 empleado sin jefe pasamos a 3. La jerarquía se ha partido en tres subárboles y la empresa se ha quedado sin dirección general en el modelo de datos. SET NULL no protesta: hace lo que se le dijo.

Resumen:

Solución 2

Dos de los cuatro se han vendido (el 10 y el 18). El LEFT JOIN con COUNT(lp.id) es el patrón exacto de 04-05: si hubiéramos usado INNER JOIN habrían desaparecido justamente los dos que nos interesan.

Falla, y falla entera. No se borran los dos que sí se podían borrar: un DELETE es atómico, igual que un INSERT o un UPDATE. La FK RESTRICT protege el histórico de facturación: sin ella, las líneas 11 y 39 (detergente) y 23, 32 y 47 (cepillo) se habrían quedado apuntando al vacío, y la facturación de 727,95 € dejaría de poder reconstruirse.

Tres actualizados, no cuatro: el producto 20 ya estaba inactivo, y el filtro AND activo lo excluye. Esto hace la sentencia idempotente (05-03): reejecutarla devolvería UPDATE 0.

Por qué esta es la solución correcta, en tres puntos: conserva el histórico de facturación intacto; mantiene la integridad referencial sin necesidad de decidir cascadas; y es reversible con un SET activo = TRUE si EcoNordic vuelve a suministrar.

Cuatro proveedores y 16 productos, frente a los cinco proveedores y 20 productos de la tabla. Fíjate en los dos filtros activo: el del producto y el del proveedor. Olvidar cualquiera de los dos devolvería un catálogo con referencias que no se pueden servir. Es exactamente el coste del borrado lógico, y exactamente lo que una vista resolvería (módulo 10).

Solución 3

1. El error. resenas aparece dos veces: como tabla destino del DELETE y dentro del USING. Es el mismo fallo que el UPDATE ... FROM del ejercicio 2 de 05-03. PostgreSQL trata la del USING como una instancia independiente, así que la condición resenas.producto_id = productos.id se resuelve contra ella y la tabla destino queda sin correlacionar. El resultado: si existe al menos una reseña de un producto inactivo, se borran todas las reseñas de la tabla. Con los datos de TiendaVerde no hay ninguna, así que borraría 0 — pero es pura suerte, y en cuanto hubiera una, se llevaría las doce.

2. La versión correcta:

Cero filas. El único producto inactivo es el 20 (Cápsulas de espirulina), y no tiene ninguna reseña — es coherente con que tampoco se haya vendido nunca. Comprobación:

3. La versión portable, sin USING:

Funciona igual en PostgreSQL, MySQL, SQLite, SQL Server y Oracle. Las subconsultas son el módulo 7, y esta es exactamente la razón por la que se estudian: USING y FROM son extensiones propietarias, la subconsulta es estándar. Ojo con un detalle heredado de 04-02: si la subconsulta pudiera devolver algún NULL, un NOT IN daría cero filas silenciosamente. Con IN no hay problema, pero conviene tenerlo presente.

4. ¿Es buena idea?

El veredicto es que no, casi nunca es buena idea. El borrado lógico existe para conservar información, y borrar físicamente las reseñas de un producto retirado destruye justo lo que hace útil la retirada: saber que ese producto tenía dos estrellas de media y por eso se retiró.

La alternativa correcta es no borrar nada y filtrar en la lectura: la web muestra las reseñas de productos vigentes, y los informes internos las ven todas. Un WHERE p.activo en la consulta pública resuelve el problema sin destruir un solo dato. Es la misma decisión de diseño de todo el apartado 9, aplicada un nivel más abajo.

Y una excepción legítima: si esas reseñas contuvieran datos personales de alguien que ha ejercido su derecho de supresión, sí habría que borrarlas — pero entonces el criterio sería el cliente, no el producto, y resenas.cliente_id ya está declarada ON DELETE CASCADE justo para eso.

DELETE cierra la trilogía del DML y plantea la pregunta que las otras dos no plantean:

• La sintaxis DELETE FROM tabla WHERE ..., con todo el peso sobre el WHERE, y el protocolo de cinco pasos reforzado con uno nuevo: contar las filas dependientes antes de borrar.
• DELETE frente a TRUNCATE: DML contra DDL, WHERE contra todo-o-nada, lento contra instantáneo, con triggers de fila contra sin ellos, y —crítico— transaccional en PostgreSQL pero no en MySQL. TRUNCATE no ejecuta las acciones ON DELETE: falla si hay FK apuntando a la tabla.
• Las tres acciones ON DELETE demostradas con recuentos: RESTRICT impide el borrado del producto 1 con su is still referenced from table; CASCADE convierte DELETE FROM pedidos WHERE id = 6 en cuatro filas de tres tablas informando de una sola; SET NULL deja los cuatro pedidos de Óscar sin comercial (10 → 14 nulos) y a tres empleados sin jefe.
• El peligro del CASCADE: alcance invisible, propagación en cadena, declarado lejos de quien ejecuta. Y la alternativa profesional, RESTRICT + borrado explícito, que cuesta tres líneas y te enseña exactamente qué destruyes.
• DELETE ... USING para borrar según otra tabla, con las mismas reglas que UPDATE ... FROM — salvo que aquí un emparejamiento 1:N no es un problema.
• RETURNING para ver la fila antes de que desaparezca, y el patrón INSERT ... SELECT + DELETE dentro de una transacción para archivarla de verdad.
• Borrado lógico frente a físico: productos.activo y proveedores.activo son borrado lógico. Conserva histórico, integridad y reversibilidad, a cambio de que todas las consultas necesiten WHERE activo — problema que resuelven las vistas del módulo 10. Y la tercera vía, fecha_baja DATE, que además te dice cuándo.
• Datos personales: activo = FALSE no cumple el derecho de supresión, la anonimización es el patrón habitual cuando choca con la obligación contable, y cualquier política de borrado de datos personales exige revisión legal.
• Recuperación: ROLLBACK si no has confirmado, copia de seguridad o PITR si sí — y ninguna de las dos existe si nadie la preparó antes.

Ya sabes insertar, modificar y borrar por separado. Falta la operación que los sistemas reales necesitan constantemente y que ninguna de las tres resuelve: "inserta esta fila si no existe, y actualízala si ya existe". Sincronizar un catálogo con el fichero de un proveedor, registrar el stock recibido de un artículo que quizá aún no está dado de alta, guardar la puntuación de una reseña que el cliente puede haber escrito antes. En la siguiente lección, Instrucción UPSERT (MERGE), verás por qué la solución evidente —consultar y luego decidir— es incorrecta en cuanto hay dos usuarios a la vez, y las dos formas que PostgreSQL ofrece para resolverlo en una sola sentencia atómica: INSERT ... ON CONFLICT y el MERGE del estándar.