Antwoord.

Gerelateerde tabellen (bijvoorbeeld "bestellingen" en "klanten") zijn vanaf het begin in relationele databases aanwezig, maar in de vroege stadia moest integriteitscontrole handmatig via programmatische logica worden gerealiseerd. Met de ontwikkeling van SQL zijn ingebouwde beperkingen (FOREIGN KEY) en automatische acties (CASCADE) ontstaan.

Geschiedenis van de kwestie:

Oorspronkelijk vereisten databases mechanismen om integriteit te waarborgen, zodat er geen "wees" records waren (bijvoorbeeld een bestelling zonder een bestaande klant). FOREIGN KEY werd de standaard en de CASCADE-opties automatiseerden synchronisatie bij deleties en wijzigingen.

Probleem:

Zonder cascade-acties leidt het verwijderen of bijwerken van een rij in de hoofdtafel tot fouten of "wees" gegevens. Het overlaten van deze taak aan de applicatie leidt vaak tot complexe ondersteuning en risico van incidenten bij massale operaties. Incorrect gebruik van cascade-acties kan leiden tot een lawine van verwijderingen of schending van bedrijfslogica.

Oplossing:

Het toepassen van FOREIGN KEY met ON DELETE CASCADE en ON UPDATE CASCADE maakt het mogelijk om automatisch de integriteit te waarborgen en de gerelateerde tabellen correct te synchroniseren. In complexe scenario's (bijvoorbeeld wanneer niet alleen verwijderingen maar ook acties gelogd moeten worden) worden triggers gebruikt.

Voorbeeldcode:

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
);

Belangrijke kenmerken:

ON DELETE CASCADE — automatisch verwijderen van ondergeschikte records bij het verwijderen van het bovenliggende record.
ON UPDATE CASCADE — automatisch bijwerken van de waarde van de foreign key.
In complexe scenario's kan implementatie via triggers voor aangepaste acties gebruikt worden.

Vragen met een valstrik.

Is cascade-verwijdering altijd de beste praktijk voor alle relaties?

Nee: voor "historische" gegevens of archiefinformatie kan cascade-verwijdering leiden tot verlies van waardevolle informatie. Het is belangrijk om de zakelijke waarde van elk type relatie te begrijpen.

Werkt ON UPDATE CASCADE als de foreign key niet deel uitmaakt van de PRIMARY KEY van de bovenliggende tabel?

In de meeste DBMS moet de foreign key verwijzen naar een unieke of PRIMARY KEY om cascades te ondersteunen. In dat geval werkt de opdracht niet.

Kan een cascade-keten de toegestane dieptelimieten (recursie) overschrijden, en wat gebeurt er dan?

Ja: bij enorme cascades is het mogelijk om de diepte limiet te overschrijden (bijvoorbeeld in SQL Server — 32). Dit leidt tot een fout en een rollback van de operatie.

Veelvoorkomende fouten en anti-patronen

Cascade-verwijdering met zwakke controle — potentieel verlies van belangrijke gegevens.
Negeert de noodzaak om massale wijzigingen te loggen.
Triggerconstructie zonder rekening te houden met prestaties (bijvoorbeeld oneindige recursie invoeren).

Voorbeeld uit het leven

Negatieve case

In het systeem voor leveranciers en bestellingen werd ON DELETE CASCADE toegepast — klanten verwijderden per ongeluk een belangrijke leverancier, waardoor automatisch alle bestellingen werden verwijderd en de leveringsgeschiedenis verloren ging. Het was onmogelijk om de gegevens te herstellen.

Voordelen:

Minimale handmatige arbeid.

Nadelen:

Verlies van bedrijfsverhaal.

Positieve case

Gebruikten ON DELETE SET NULL, plus een trigger voor logging — zelfs na het verwijderen van het klantrecord bleef de bestellingsgeschiedenis behouden (status werd niet-actueel toegewezen), er vond geen toevallige massale verwijdering plaats.