DELETE elimina files. És l'operació més senzilla del mòdul i la que exigeix més criteri, perquè planteja una pregunta que INSERT i UPDATE no plantegen: de debò cal esborrar-ho?

BotigaVerda ja te'n va donar la resposta sense dir-t'ho. Les seves taules productes i proveidors tenen una columna actiu. Aquell booleà existeix perquè, en un sistema real, un producte que s'ha venut no s'esborra mai: es retira del catàleg. Esborrar-lo destruiria l'històric de facturació, i de fet la clau forana linies_comanda.producte_id → productes.id està declarada ON DELETE RESTRICT precisament per impedir-ho. Tota aquella discussió —esborrat lògic davant d'esborrat físic— té aquí la seva lliçó.

Abans arribarem al concret: el protocol de seguretat reforçat, la diferència entre DELETE i TRUNCATE, i què passa exactament en esborrar una fila de la qual en depenen d'altres, demostrat amb recomptes abans i després per a les tres accions ON DELETE que BotigaVerda declara.

⚠️ Avís de seguretat

DELETE és una operació destructiva i irreversible un cop confirmada. A diferència d'UPDATE, que substitueix un valor per un altre, DELETE fa desaparèixer la fila sencera — i, amb ON DELETE CASCADE, files d'altres taules que no has esmentat.

• Executa tots els exemples sobre la teva base de dades de pràctiques (botigaverda), mai en producció.
• Fes una còpia de seguretat prèvia: pg_dump -U curs_sql -d botigaverda -f copia.sql. Per tornar a l'estat inicial n'hi ha prou amb rellançar botigaverda.sql.
• Treballa sempre dins de BEGIN … ROLLBACK / COMMIT mentre experimentes.
• En un sistema real, un esborrat sobre dades vives ha d'anar revisat per una altra persona, i les polítiques d'esborrat de dades personals requereixen revisió legal (apartat 9).

1. La sintaxi, i el protocol reforçat
2. DELETE sense WHERE davant de TRUNCATE
3. Esborrar una fila referenciada: RESTRICT
4. Esborrar una fila referenciada: CASCADE
5. Esborrar una fila referenciada: SET NULL
6. El perill del CASCADE i l'alternativa professional
7. DELETE ... USING: esborrar segons una altra taula
8. RETURNING: conservar el que esborres
9. Esborrat lògic davant d'esborrat físic
10. Dades personals i dret de supressió
11. Recuperació després d'un esborrat accidental
12. Errors habituals i consells
13. Exercicis
14. Conclusió

Només dues peces: quina taula i quines files. No hi ha SET, no hi ha valors. Tota la responsabilitat recau sobre el WHERE.

Igual que UPDATE N, el número et diu quantes files ha eliminat. I aquí importa encara més, perquè no hi ha cap valor nou que puguis inspeccionar després: si el número no és el que esperaves, ja és tard.

El protocol dels cinc passos de 05-03 s'aplica igual, amb dos reforços:

El pas 3 és el nou, i és el que distingeix un DELETE segur d'una catàstrofe. Abans d'esborrar una comanda, mira quantes línies i devolucions té:

Ara ja saps que aquell DELETE 1 eliminarà quatre files en tres taules. L'apartat 4 ho demostra.

I el flux complet:

Sense WHERE, DELETE buida la taula:

Les dotze ressenyes, fora. Exactament el mateix problema que l'UPDATE sense WHERE, amb la mateixa absència d'avís.

Per buidar una taula hi ha una instrucció específica, TRUNCATE:

Fan el mateix i no s'assemblen en res:

Aquella última fila mereix una demostració:

TRUNCATE no executa les accions ON DELETE: o buides tot l'arbre alhora, o no en buides res.

I si a més vols que les seqüències tornin a començar a 1:

Quan fer servir cadascun. TRUNCATE per buidar taules de treball, d'staging o de proves, on vols començar de zero i la velocitat importa. DELETE per a tota la resta, i sempre que hi hagi un WHERE pel mig. Un DELETE FROM taula; sense condició sobre una taula gran és el pitjor dels dos móns: lent, amb el WAL disparat i sense alliberar espai.

Aquí comença l'interessant. Quan la fila que esborres és el "pare" d'una clau forana, el motor aplica l'acció declarada a l'ON DELETE. BotigaVerda declara les tres.

RESTRICT és la barrera: prohibeix esborrar. La porta linies_comanda.producte_id, entre d'altres.

El producte 1 (Oli d'oliva) apareix en 5 línies de comanda i té 2 ressenyes:

Llegeix-lo amb calma, perquè és l'error més freqüent del mòdul:

Compara'l amb l'error d'INSERT de 05-02: allà deia is not present in table (referenciaves una cosa que no existeix); aquí diu is still referenced from table (una cosa depèn del que vols esborrar). Les dues meitats de la integritat referencial.

Ara un producte que sí que es pot esborrar. El 19 (Desodorant natural) és un dels tres que no s'han venut mai, i no té ressenyes:

Del catàleg de 20 en queden 19. La restricció RESTRICT no és un obstacle: és una funció. T'està dient "aquest producte té història, no el destrueixis". I el producte 19 no en té.

CASCADE propaga l'esborrat a les files filles. A BotigaVerda el porten quatre claus foranes: linies_comanda.comanda_id, devolucions.comanda_id, ressenyes.producte_id i ressenyes.client_id.

La comanda 6 és el cas perfecte: està cancel·lada, té 2 línies i 1 devolució.

I el que penja de la comanda 6:

Ara l'esborrat:

DELETE 1. Una sola fila, diu PostgreSQL. Mirem els recomptes:

Han desaparegut quatre files en tres taules, i el comptador només n'ha informat d'una. Aquí està, en tota la seva cruesa, el perill del CASCADE: DELETE N compta les files que tu has esborrat, no les que el motor ha esborrat en cadena.

I les cascades es poden encadenar. Si linies_comanda tingués al seu torn una taula filla amb CASCADE, l'esborrat continuaria baixant. En un esquema gran, un sol DELETE es pot propagar per mitja base de dades sense que res t'ho indiqui.

La manera de no endur-te sorpreses és preguntar al catàleg del sistema quines claus foranes apunten a una taula:

Més ràpid encara, dins de psql, la secció Referenced by de \d comandes:

Consell: fes \d taula abans de qualsevol DELETE sobre una taula que no coneguis al dit. La secció Referenced by et diu en cinc segons si desencadenaràs una cascada.

SET NULL no esborra el fill: li treu la referència. BotigaVerda ho declara a comandes.empleat_id, clients.referit_per_id i empleats.cap_id.

El comercial Óscar Peris Blasco (empleat 4) deixa l'empresa. Té 4 comandes assignades:

Les 20 comandes continuen allà. El que ha canviat és que les quatre de l'Óscar ara tenen empleat_id a NULL: de 10 comandes sense comercial hem passat a 14.

I aquí hi ha una lliçó de 04-03 que convé subratllar. Abans, empleat_id IS NULL significava inequívocament "comanda entrada pel web". Ara significa dues coses diferents: "comanda web" o "el comercial que la va gestionar ja no és a l'empresa". El NULL ha perdut precisió semàntica sense que ningú no ho hagi decidit. És un efecte secundari clàssic de SET NULL, i la raó que molts equips prefereixin conservar l'empleat amb una marca de baixa en lloc d'esborrar-lo.

Un cas més vistós: esborrar l'Andrés Company Talens (empleat 2), Responsable de vendes, que no gestiona cap comanda però té tres subordinats.

Tres empleats s'han quedat sense cap, i l'organigrama que 01-06 dibuixava amb tanta pulcritud té ara quatre arrels en lloc d'una. L'empresa no s'ha reorganitzat: simplement ha desaparegut un node intermedi de l'arbre i SET NULL ha fet l'única cosa que sap fer.

CASCADE és còmode. Un DELETE i tot l'arbre desapareix netament, sense files òrfenes. I precisament per això és perillós:

Per això molts equips adopten una política més conservadora: RESTRICT a totes les FK, i esborrat explícit en l'ordre correcte, dins d'una transacció.

Compara les dues sortides. Amb CASCADE: DELETE 1, i quatre files fora. Explícitament: DELETE 1, DELETE 2, DELETE 1 — quatre files, i les veus totes. Escrius tres línies en lloc d'una i guanyes visibilitat completa sobre el que estàs destruint. En un sistema amb dades reals, aquell canvi val molt més del que costa.

BotigaVerda fa servir CASCADE en quatre llocs i tots quatre són composició real: una línia de comanda, una devolució i una ressenya no signifiquen res sense el seu pare. És l'ús correcte. La regla de 01-05 continua vigent: pregunta't si la fila filla té sentit per si sola, i si dubtes, RESTRICT.

Igual que UPDATE té FROM, DELETE té USING: permet decidir què esborrar en funció d'una altra taula.

Depuració del catàleg: eliminar les línies de les comandes cancel·lades.

Regles d'USING, totes heretades d'UPDATE ... FROM:

• Pots posar-hi diverses taules, separades per comes o amb JOIN.
• La taula destinació no es repeteix a l'USING. Si ho fas, producte cartesià silenciós.
• Al contrari que a UPDATE ... FROM, un aparellament 1:N no és un problema aquí: una fila que aparella amb tres s'esborra una sola vegada. DELETE és idempotent per naturalesa.

Nota de dialecte: USING és de PostgreSQL. MySQL escriu DELETE lc FROM linies_comanda lc JOIN comandes co ON ... WHERE ... (fixa't en l'àlies repetit després de DELETE). SQL Server fa servir DELETE d FROM desti d JOIN altra a ON .... Oracle no té cap de les dues i obliga a una subconsulta correlacionada. La forma portable és sempre una subconsulta: DELETE FROM linies_comanda WHERE comanda_id IN (SELECT id FROM comandes WHERE estat = 'cancellat') — mòdul 7.

A DELETE, RETURNING retorna les files tal com eren just abans de desaparèixer. És l'única manera de veure-les sense haver-les consultat abans.

Però veure-les no és conservar-les. Per a això, el patró professional combina INSERT ... SELECT (05-02) amb el DELETE, dins d'una transacció:

Dins d'una transacció, o passen les tres coses o no en passa cap: és impossible que esborris sense haver arxivat. Fixa't en un detall del DDL de la taula d'arxiu: no porta claus foranes. Si en portés, no podries arxivar una devolució la comanda de la qual també s'esborrarà. Les taules d'arxiu són deliberadament laxes.

RETURNING completa la trilogia: INSERT ... RETURNING et dóna l'id generat, UPDATE ... RETURNING el valor nou, DELETE ... RETURNING la fila que se'n va. En els tres casos evita un SELECT addicional i la condició de cursa que porta associada.

I arribem al fons de la qüestió.

• Esborrat físic: DELETE FROM productes WHERE id = 13. La fila desapareix.
• Esborrat lògic: UPDATE productes SET actiu = FALSE WHERE id = 13. La fila continua allà, marcada com a no vigent.

productes.actiu i proveidors.actiu són exactament això. No són un caprici del disseny: són la decisió, presa a 01-05 i ara explicada, que a BotigaVerda res que hagi participat en una operació comercial no s'esborra mai.

EcoNordic Supplies està inactiu i conserva els seus quatre productes al catàleg (10, 13, 18 i 20). Amb un esborrat físic, o bé la FK RESTRICT hauria impedit esborrar-lo, o bé hauries hagut d'esborrar quatre productes que encara es venen.

Aquest és l'inconvenient que tothom subestima:

Cinc categories, no sis. Complements desapareix de l'informe perquè el seu únic producte (el 20) està inactiu. I aquella desaparició depèn enterament que algú es recordés d'escriure WHERE p.actiu. Oblidar-ho una sola vegada en un informe de direcció i estaràs comptant referències que ja no es venen.

Aquell oblit té solució, i és una vista:

A partir d'aquí, les consultes de catàleg van contra productes_vigents i el filtre és impossible d'oblidar. Les vistes són la solució canònica al principal inconvenient de l'esborrat lògic, i s'estudien a la lliçó 10-01.

I una tercera via, cada cop més habitual: esborrat lògic amb data. En lloc d'un booleà, una columna data_baixa DATE nul·lable. Ocupa el mateix, distingeix "vigent" de "donat de baixa" igual de bé (data_baixa IS NULL) i a més et diu quan va passar, que sol ser just el que preguntarà algú sis mesos després. Si dissenyes de zero, prefereix-la al booleà.

Hi ha un cas on l'esborrat lògic no n'hi ha prou: les dades personals.

El Reglament General de Protecció de Dades europeu reconeix el dret de supressió (article 17, l'anomenat "dret a l'oblit"): una persona pot exigir que les seves dades personals s'eliminin, i marcar una fila com a inactiva no és eliminar-la. El nom, l'email i la ciutat continuen a la taula, a les còpies de seguretat i als índexs.

A BotigaVerda, la taula clients conté dades personals: nom, cognoms, email i ciutat. I el seu disseny ja anticipa part del problema:

Núria Bosch Ferrer (client 13) és un dels tres clients sense comandes. El seu esborrat és net:

Però amb un client que sí que ha comprat, el conflicte apareix immediatament:

Ana Belmonte Roca té dues comandes (la 6 i la 18), i comandes.client_id és RESTRICT. Aquí xoquen dues obligacions legítimes:

La solució habitual en sistemes reals no és ni esborrar ni no esborrar: és anonimitzar. Es conserva la fila —i amb ella la comanda, la factura i els totals— però se substitueixen les dades identificatives:

La comanda 6 continua existint, la comptabilitat quadra, i la dada personal ha desaparegut. L'email es construeix amb l'id per no trencar la restricció UNIQUE, i amb un domini invàlid perquè sigui impossible enviar correu a aquella adreça per accident.

Les ressenyes, en canvi, sí que s'esborren: ressenyes.client_id està declarada ON DELETE CASCADE exactament per aquest motiu, com vas raonar a l'exercici 1 de 01-05. Una ressenya és una opinió personal; una factura és un document comptable.

⚖️ Avís important

L'anterior és una explicació tècnica de patrons habituals, no assessorament jurídic. Els terminis de conservació, què es considera dada personal, quin grau d'anonimització és suficient i quines excepcions apliquen depenen de la legislació vigent, del sector i del cas concret.

Abans d'implantar qualsevol política d'esborrat o anonimització de dades personals en un sistema real, consulta-ho amb el responsable de protecció de dades o amb assessoria jurídica. Un DELETE mal plantejat pot incomplir l'RGPD; un de ben intencionat pot incomplir la normativa comptable. La seguretat, els permisos i el control d'accés a aquestes dades s'estudien a la lliçó 11-03.

Ha passat. Has confirmat un DELETE que no havies de fer. Quines opcions hi ha?

PITR (Point-In-Time Recovery) és la tècnica que permet dir "torna'm la base tal com estava a les 17:42:30 d'ahir". Funciona perquè PostgreSQL escriu tots els canvis en un registre seqüencial —el WAL, Write-Ahead Log— abans d'aplicar-los als fitxers de dades. Amb una còpia base i el WAL posterior es pot reconstruir qualsevol instant intermedi. És també el mecanisme que fa possibles la durabilitat i la replicació, i s'estudia amb la resta del model transaccional al mòdul 9.

La conclusió pràctica, que no depèn de cap tecnologia:

No hi ha recuperació sense còpia de seguretat. L'única pregunta que importa no és "què faig si esborro alguna cosa per error?", sinó "quan es va fer l'última còpia i quan es va provar per última vegada a restaurar-la?". Una còpia que mai no s'ha restaurat no és una còpia: és una suposició.

Per al curs, la teva xarxa de seguretat és molt més simple: botigaverda.sql és idempotent, i rellançar-lo et torna a l'estat inicial en dos segons.

• Oblidar el WHERE. Buida la taula sencera sense avís. Mateix error emblemàtic que a UPDATE, amb conseqüències pitjors.
• Refiar-se del DELETE N amb CASCADE. Compta les files que esborres tu, no les que esborra el motor en cadena. DELETE 1 pot ser quatre files, o quatre milions.
• No comprovar què depèn de la fila abans d'esborrar-la. \d taula i la seva secció Referenced by en cinc segons.
• Fer servir TRUNCATE creient que és un DELETE ràpid. No admet WHERE, no dispara triggers de fila, no retorna recompte, exigeix un altre permís i falla si hi ha FK apuntant a la taula.
• Comptar que TRUNCATE sigui transaccional. A PostgreSQL sí; a MySQL no, i allà no hi ha ROLLBACK possible.
• Repetir la taula destinació a l'USING. Producte cartesià silenciós, igual que a UPDATE ... FROM.
• Esborrar registres amb històric comercial. Per a això hi ha actiu = FALSE. La FK RESTRICT intentarà frenar-te; no l'esquivis amb CASCADE.
• Implantar esborrat lògic i oblidar el WHERE actiu. L'informe continuarà funcionant i comptarà productes descatalogats. Fes servir una vista (mòdul 10).
• Creure que actiu = FALSE compleix el dret de supressió. No el compleix: la dada personal continua allà. Anonimitzar o esborrar, segons el cas i amb revisió legal.
• Confondre "no té fills avui" amb "es pot esborrar". El producte 19 es pot esborrar avui; demà, tan bon punt algú el compri, ja no.
• Consell: SELECT * abans de qualsevol DELETE. Vols veure la fila completa que desapareixerà, no només el seu id.
• Consell: RETURNING * sempre en un DELETE. No costa res i et deixa constància del que has esborrat, encara que sigui a l'historial de la consola.
• Consell: prefereix RESTRICT + esborrat explícit a CASCADE. Tres línies en lloc d'una, a canvi de veure exactament què destrueixes.
• Consell: en dissenyar, fes servir data_baixa DATE en lloc d'actiu BOOLEAN. Costa el mateix i a més et diu quan.

Treballa sobre la base acabada de recarregar i fes servir BEGIN … ROLLBACK a tots els exercicis.

Per a cadascun d'aquests cinc esborrats, prediu el resultat abans d'executar-lo: si funciona o falla, quantes files s'eliminen en total i en quines taules, i quina acció ON DELETE hi intervé. Després comprova-ho amb recomptes abans i després.

Direcció demana retirar del catàleg tots els productes del proveïdor inactiu (EcoNordic Supplies, id 5).

1. Comprova quins són i quins d'ells s'han venut alguna vegada.
2. Intenta l'esborrat físic de tots i explica què passa.
3. Proposa i aplica la solució correcta, justificant per què és la correcta.
4. Escriu la consulta de catàleg vigent que hauria de fer servir el web a partir d'ara, agrupada per proveïdor.

Un company vol netejar les ressenyes de productes descatalogats i t'ensenya aquesta sentència:

1. Troba l'error i explica què faria realment.
2. Escriu-la correctament i digues quantes files esborraria sobre la base acabada de recarregar.
3. Reescriu-la de manera portable, sense USING, indicant quin mòdul cobreix aquella tècnica.
4. Discuteix si aquesta neteja és bona idea: què es perd i què es guanya?

Solució 1

a) Falla. productes.proveidor_id és ON DELETE RESTRICT i EcoNordic té quatre productes:

Que el proveïdor estigui actiu = FALSE no canvia res: l'esborrat lògic i la integritat referencial són mecanismes independents.

b) Funciona, i esborra 4 files en 3 taules. La comanda 10 té 2 línies (ids 24 i 25) i 1 devolució (la 2, de 34,02 €), totes dues amb CASCADE:

I una cosa que no apareix en cap recompte: la facturació total de BotigaVerda acaba de baixar de 727,95 € a 679,68 €, perquè la comanda 10 aportava 48,27 €. Els ports baixen de 118,25 € a 105,75 €. Cap missatge t'ho ha dit.

c) Falla, i és l'exercici trampa. La categoria 6 (Complements) sembla buida perquè el seu únic producte, el 20, està descatalogat. Però productes.categoria_id és RESTRICT i aquella fila continua existint:

El producte 20 està actiu = FALSE, però continua sent una fila de productes i la clau forana no distingeix entre actiu i inactiu. L'esborrat lògic no allibera les restriccions referencials.

d) Funciona, 1 fila. Hugo Iglesias Pardo (client 14) és un dels tres sense comandes, no té ressenyes i no ha referit ningú:

clients: 15 → 14. Cap cascada, cap SET NULL. És l'únic dels cinc esborrats veritablement innocu.

e) Funciona, i desmunta l'organigrama. Rosa Alcázar Vives (empleada 1) no gestiona comandes, però és cap de tres persones (2, 3 i 8), i empleats.cap_id és SET NULL:

D'1 empleat sense cap passem a 3. La jerarquia s'ha partit en tres subarbres i l'empresa s'ha quedat sense direcció general al model de dades. SET NULL no protesta: fa el que se li va dir.

Resum:

Solució 2

Dos dels quatre s'han venut (el 10 i el 18). El LEFT JOIN amb COUNT(lc.id) és el patró exacte de 04-05: si haguéssim fet servir INNER JOIN haurien desaparegut justament els dos que ens interessen.

Falla, i falla sencera. No s'esborren els dos que sí que es podien esborrar: un DELETE és atòmic, igual que un INSERT o un UPDATE. La FK RESTRICT protegeix l'històric de facturació: sense ella, les línies 11 i 39 (detergent) i 23, 32 i 47 (raspall) s'haurien quedat apuntant al buit, i la facturació de 727,95 € deixaria de poder reconstruir-se.

Tres actualitzats, no quatre: el producte 20 ja estava inactiu, i el filtre AND actiu l'exclou. Això fa la sentència idempotent (05-03): reexecutar-la retornaria UPDATE 0.

Per què aquesta és la solució correcta, en tres punts: conserva l'històric de facturació intacte; manté la integritat referencial sense necessitat de decidir cascades; i és reversible amb un SET actiu = TRUE si EcoNordic torna a subministrar.

Quatre proveïdors i 16 productes, davant dels cinc proveïdors i 20 productes de la taula. Fixa't en els dos filtres actiu: el del producte i el del proveïdor. Oblidar qualsevol dels dos retornaria un catàleg amb referències que no es poden servir. És exactament el cost de l'esborrat lògic, i exactament el que una vista resoldria (mòdul 10).

Solució 3

1. L'error. ressenyes apareix dues vegades: com a taula destinació del DELETE i dins de l'USING. És la mateixa fallada que l'UPDATE ... FROM de l'exercici 2 de 05-03. PostgreSQL tracta la de l'USING com una instància independent, així que la condició ressenyes.producte_id = productes.id es resol contra ella i la taula destinació queda sense correlacionar. El resultat: si existeix almenys una ressenya d'un producte inactiu, s'esborren totes les ressenyes de la taula. Amb les dades de BotigaVerda no n'hi ha cap, així que n'esborraria 0 — però és pura sort, i tan bon punt n'hi hagués una, s'enduria les dotze.

2. La versió correcta:

Zero files. L'únic producte inactiu és el 20 (Càpsules d'espirulina), i no té cap ressenya — és coherent amb el fet que tampoc no s'hagi venut mai. Comprovació:

3. La versió portable, sense USING:

Funciona igual a PostgreSQL, MySQL, SQLite, SQL Server i Oracle. Les subconsultes són el mòdul 7, i aquesta és exactament la raó per la qual s'estudien: USING i FROM són extensions propietàries, la subconsulta és estàndard. Compte amb un detall heretat de 04-02: si la subconsulta pogués retornar algun NULL, un NOT IN donaria zero files silenciosament. Amb IN no hi ha problema, però convé tenir-ho present.

4. És bona idea?

El veredicte és que no, gairebé mai no és bona idea. L'esborrat lògic existeix per conservar informació, i esborrar físicament les ressenyes d'un producte retirat destrueix just el que fa útil la retirada: saber que aquell producte tenia dues estrelles de mitjana i per això es va retirar.

L'alternativa correcta és no esborrar res i filtrar en la lectura: el web mostra les ressenyes de productes vigents, i els informes interns les veuen totes. Un WHERE p.actiu a la consulta pública resol el problema sense destruir ni una sola dada. És la mateixa decisió de disseny de tot l'apartat 9, aplicada un nivell més avall.

I una excepció legítima: si aquelles ressenyes contenien dades personals d'algú que ha exercit el seu dret de supressió, sí que caldria esborrar-les — però llavors el criteri seria el client, no el producte, i ressenyes.client_id ja està declarada ON DELETE CASCADE just per a això.

DELETE tanca la trilogia del DML i planteja la pregunta que les altres dues no plantegen:

• La sintaxi DELETE FROM taula WHERE ..., amb tot el pes sobre el WHERE, i el protocol de cinc passos reforçat amb un de nou: comptar les files dependents abans d'esborrar.
• DELETE davant de TRUNCATE: DML contra DDL, WHERE contra tot-o-res, lent contra instantani, amb triggers de fila contra sense, i —crític— transaccional a PostgreSQL però no a MySQL. TRUNCATE no executa les accions ON DELETE: falla si hi ha FK apuntant a la taula.
• Les tres accions ON DELETE demostrades amb recomptes: RESTRICT impedeix l'esborrat del producte 1 amb el seu is still referenced from table; CASCADE converteix DELETE FROM comandes WHERE id = 6 en quatre files de tres taules informant d'una de sola; SET NULL deixa les quatre comandes de l'Óscar sense comercial (10 → 14 nuls) i tres empleats sense cap.
• El perill del CASCADE: abast invisible, propagació en cadena, declarat lluny de qui executa. I l'alternativa professional, RESTRICT + esborrat explícit, que costa tres línies i t'ensenya exactament què destrueixes.
• DELETE ... USING per esborrar segons una altra taula, amb les mateixes regles que UPDATE ... FROM — llevat que aquí un aparellament 1:N no és un problema.
• RETURNING per veure la fila abans que desaparegui, i el patró INSERT ... SELECT + DELETE dins d'una transacció per arxivar-la de debò.
• Esborrat lògic davant de físic: productes.actiu i proveidors.actiu són esborrat lògic. Conserva històric, integritat i reversibilitat, a canvi que totes les consultes necessitin WHERE actiu — problema que resolen les vistes del mòdul 10. I la tercera via, data_baixa DATE, que a més et diu quan.
• Dades personals: actiu = FALSE no compleix el dret de supressió, l'anonimització és el patró habitual quan xoca amb l'obligació comptable, i qualsevol política d'esborrat de dades personals exigeix revisió legal.
• Recuperació: ROLLBACK si no has confirmat, còpia de seguretat o PITR si sí — i cap de les dues existeix si ningú no la va preparar abans.

Ja saps inserir, modificar i esborrar per separat. Falta l'operació que els sistemes reals necessiten constantment i que cap de les tres no resol: "insereix aquesta fila si no existeix, i actualitza-la si ja existeix". Sincronitzar un catàleg amb el fitxer d'un proveïdor, registrar l'estoc rebut d'un article que potser encara no està donat d'alta, desar la puntuació d'una ressenya que el client pot haver escrit abans. A la lliçó següent, Instrucció UPSERT (MERGE), veuràs per què la solució evident —consultar i després decidir— és incorrecta tan bon punt hi ha dos usuaris alhora, i les dues formes que PostgreSQL ofereix per resoldre-ho en una sola sentència atòmica: INSERT ... ON CONFLICT i el MERGE de l'estàndard.