Antwoord

Triggers zijn speciale database-objecten die automatisch een bepaald stuk code (meestal in SQL of procedurele extensietalen zoals PL/pgSQL voor PostgreSQL) uitvoeren wanneer een gebeurtenis zich voordoet: INSERT, UPDATE of DELETE op een tabel.

Voordelen:

• Gecentraliseerde toepassing van bedrijfslogica en gegevensvalidatie.
• Automatisering van audits (bijvoorbeeld veranderingen in de geschiedenis).

Nadelen:

• Verborgen uitvoering - het is niet altijd duidelijk dat een trigger is uitgevoerd.
• Verminderde prestaties bij frequente wijzigingen in tabellen.
• Moeilijkheden bij debugging en foutopsporing, risico van eindeloze lussen (recursieve triggers).
• Data-migraties worden complexer.

Wanneer te gebruiken:

• Gegevensaudits.
• Automatische creatie van gerelateerde records.
• Implementatie van controlebeperkingen die niet mogelijk zijn met standaardmiddelen.

Voorbeeld van een trigger (PostgreSQL):

CREATE TABLE employee_audit (
  id SERIAL PRIMARY KEY,
  employee_id INT,
  old_salary NUMERIC,
  new_salary NUMERIC,
  changed_at TIMESTAMP
);

CREATE OR REPLACE FUNCTION audit_salary()
RETURNS TRIGGER AS $$
BEGIN
  IF NEW.salary <> OLD.salary THEN
    INSERT INTO employee_audit(employee_id, old_salary, new_salary, changed_at)
    VALUES (OLD.id, OLD.salary, NEW.salary, NOW());
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_salary_update
AFTER UPDATE ON employees
FOR EACH ROW
EXECUTE FUNCTION audit_salary();

Vraag met een valstrik

Is het mogelijk om binnen een trigger dezelfde tabel bij te werken waarop deze is ingesteld? Wat zal er gebeuren?

Antwoord:
Als de trigger is ingesteld om te reageren op een UPDATE van de tabel en binnenin een andere UPDATE van dezelfde tabel uitvoert, leidt dit tot een eindeloze recursie (loop) en een crash van de opdracht of een fout vanwege het overschrijden van de diepte van de triggers. Daarom moet je altijd controleren om er zeker van te zijn dat er geen recursie optreedt, of gebruik opties die recursieve oproepen toestaan of verbieden.

Voorbeeld:

-- Met deze constructie kan de trigger worden vastgelopen:
CREATE OR REPLACE FUNCTION recursive_update()
RETURNS TRIGGER AS $$
BEGIN
  UPDATE employees SET salary = salary * 1.01 WHERE id = NEW.id; -- zal opnieuw afgaan
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

---

Geschiedenis

In de boekhoud-CRM werd een trigger geïmplementeerd voor het automatisch vastleggen van acties in de log bij het wijzigen van de transactietabel. Onder hoge belasting begon de dienst trager te werken, en analyse toonde aan: de trigger gaf veel tijd uit aan het invoegen in de log en was niet geoptimaliseerd (bijvoorbeeld, het registreerde alleen belangrijke gebeurtenissen).

---

Geschiedenis

In een project voor voorraadbeheer werd een BEFORE INSERT-trigger gebruikt voor het berekenen van de positie-ID. Onjuiste logica van de ID veroorzaakte duplicatie van gegevens, en de fout bleef lange tijd onopgemerkt omdat deze "op de achtergrond" werkte.

---

Geschiedenis

In een HR-platform voerde een trigger massale updates uit van records in de bovenliggende en onderliggende tabellen bij elke INSERT. Door fouten in de logica van de trigger ontstond er recursie, waardoor alle operaties op de tabellen volledig werden geblokkeerd. De trigger moest worden uitgeschakeld en een complexe rollback-mitatie moest worden uitgevoerd om de tabellen te deblokkeren.