Odpowiedź

Wyzwalacze — specjalne obiekty bazy danych, które automatycznie uruchamiają wykonanie określonego kodu (zwykle w SQL lub językach rozszerzeń proceduralnych, np. PL/pgSQL dla PostgreSQL) w momencie wystąpienia zdarzenia: INSERT, UPDATE lub DELETE na tabeli.

Zalety:

• Centralizacja stosowania logiki biznesowej i walidacji danych.
• Automatyzacja audytu (np. historia zmian).

Wady:

• Ukryte wykonanie — nie zawsze jest oczywiste, że wyzwalacz został uruchomiony.
• Spadek wydajności przy częstych zmianach w tabelach.
• Trudności w debugowaniu i testowaniu, ryzyko zapętlenia (wyzwalacze rekurencyjne).
• Migracje danych stają się trudniejsze.

Kiedy stosować:

• Audyt danych.
• Automatyczne tworzenie powiązanych rekordów.
• Realizacja kontroli ograniczeń, niemożliwych do zrealizowania standardowymi środkami.

Przykład wyzwalacza (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();

Pytanie z haczykiem

Czy wewnątrz wyzwalacza można zaktualizować tę samą tabelę, w której jest ustawiony? Co się stanie?

Odpowiedź:
Jeśli wyzwalacz jest skonfigurowany na zdarzenie, powiedzmy, UPDATE tabeli i wewnątrz wykonuje ponowny UPDATE tej samej tabeli, spowoduje to wystąpienie nieskończonej rekurencji (zapętlenia) i awaryjnego zakończenia polecenia lub błąd przekroczenia głębokości wyzwalaczy. Dlatego zawsze kontroluj, aby nie występowała rekurencja lub używaj opcji zezwalających/zabraniających rekurencyjnych wywołań.

Przykład:

-- Taki konstrukcji można załadować wyzwalacz:
CREATE OR REPLACE FUNCTION recursive_update()
RETURNS TRIGGER AS $$
BEGIN
  UPDATE employees SET salary = salary * 1.01 WHERE id = NEW.id; -- uruchomi się ponownie
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

---

Historia

W księgowej CRM wdrożono wyzwalacz do automatycznego rejestrowania operacji w logu przy zmianie tabeli transakcji. Przy dużym obciążeniu serwis zaczął działać wolniej, a analiza pokazała: wyzwalacz poświęca zbyt dużo czasu na wstawianie do logu i nie był zoptymalizowany (na przykład, nie zapisywał tylko istotnych zdarzeń).

---

Historia

W projekcie zarządzania inwentaryzacją używano wyzwalacza BEFORE INSERT do obliczania ID pozycji. Błędna logika ID spowodowała duplikację danych, a błąd długo pozostawał niezauważony, ponieważ działał „w tle”.

---

Historia

W platformie HR wyzwalacz dokonywał masowej aktualizacji rekordów w tabelach nadrzędnych i podrzędnych przy każdym INSERT. Z powodu błędów w logice wyzwalacza wystąpiła rekurencja, co całkowicie zablokowało wszystkie operacje na tabelach. Konieczne było wyłączenie wyzwalacza i przeprowadzenie skomplikowanej rollback-mitacji, aby odblokować tabele.