Risposta

Trigger — oggetti speciali del database che avviano automaticamente l'esecuzione di un determinato codice (di solito in SQL o linguaggi di estensione procedurale, come PL/pgSQL per PostgreSQL) al verificarsi di un evento: INSERT, UPDATE o DELETE su una tabella.

Vantaggi:

• Applicazione centralizzata della logica aziendale e convalida dei dati.
• Automazione dell'audit (ad esempio, cronologia delle modifiche).

Svantaggi:

• Esecuzione nascosta — non sempre è ovvio che il trigger sia stato eseguito.
• Riduzione delle prestazioni in caso di frequenti modifiche alle tabelle.
• Difficoltà di debug e di risoluzione dei problemi, rischio di ciclicità (trigger ricorsivi).
• Le migrazioni dei dati diventano più complesse.

Quando applicare:

• Audit dei dati.
• Creazione automatica di record correlati.
• Implementazione di controlli di vincoli impossibili con i mezzi standard.

Esempio di 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();

Domanda insidiosa

È possibile aggiornare all'interno di un trigger la stessa tabella su cui è stato impostato? Cosa succede?

Risposta:
Se un trigger è impostato su un evento, ad esempio, UPDATE della tabella e all'interno di esso esegue un altro UPDATE su quella stessa tabella, ciò porterà alla generazione di una ricorsione infinita (ciclone) e alla terminazione anomala del comando o all'errore di superamento della profondità dei trigger. Pertanto, controlla sempre che non si generi ricorsione, o utilizza opzioni che consentano/vietino chiamate ricorsive.

Esempio:

-- Questa costruzione può causare un ciclo nel trigger:
CREATE OR REPLACE FUNCTION recursive_update()
RETURNS TRIGGER AS $$
BEGIN
  UPDATE employees SET salary = salary * 1.01 WHERE id = NEW.id; -- si attiverà di nuovo
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

---

Storia

In un CRM contabile è stato implementato un trigger per la registrazione automatica delle operazioni nel log al momento della modifica della tabella delle transazioni. Sotto carico elevato, il servizio ha iniziato a funzionare più lentamente e l'analisi ha mostrato: il trigger impiega molto tempo per inserire nel log e non era ottimizzato (ad esempio, non registrava solo eventi significativi).

---

Storia

Nel progetto di gestione dell'inventario è stato utilizzato un trigger BEFORE INSERT per calcolare l'ID della posizione. La logica scorretta dell'ID ha provocato la duplicazione dei dati, e l'errore è rimasto a lungo inosservato perché funzionava "in background".

---

Storia

In una piattaforma HR, il trigger effettuava un aggiornamento di massa dei record nelle tabelle madre e figlia ad ogni INSERT. A causa di errori nella logica del trigger è emersa la ricorsione, bloccando completamente tutte le operazioni con le tabelle. È stato necessario disattivare il trigger e fare una complessa mitigazione di rollback per sbloccare le tabelle.