Generator wyzwalacza SQL

Wyzwalacz SQL (trigger): co to jest

Wyzwalacz SQL (trigger) to kod, który baza danych uruchamia automatycznie przy INSERT, UPDATE lub DELETE na wskazanej tabeli. Utrzymuje znaczniki czasu, prowadzi audyt, pilnuje poprawności danych albo aktualizuje powiązane tabele. Generator składa gotowe polecenie CREATE TRIGGER dla MySQL / MariaDB oraz PostgreSQL.

Rodzaje wyzwalaczy

W wyzwalaczu INSERT dostępny jest tylko rekord NEW, w DELETE tylko OLD, a w UPDATE oba. Wartości NEW można zmieniać wyłącznie w BEFORE; OLD służy tylko do odczytu.

Dobre praktyki

• nie umieszczaj ciężkiej logiki w triggerach — trudno je debugować,
• uważaj na rekurencję: w PostgreSQL trigger zmieniający własną tabelę uruchomi się ponownie, a MySQL takiej zmiany w ogóle nie wykona,
• dokumentuj każdy wyzwalacz i jego skutki, najlepiej w migracjach razem ze schematem,
• w PostgreSQL wyzwalacz zawsze wywołuje funkcję (CREATE TRIGGER ... EXECUTE FUNCTION); generator tworzy ją razem z wyzwalaczem.

Jak działa generator wyzwalacza SQL

Podajesz bazę danych (MySQL / MariaDB albo PostgreSQL), nazwę wyzwalacza, tabelę, moment (BEFORE lub AFTER), zdarzenie (INSERT, UPDATE, DELETE) oraz treść, czyli instrukcje SQL do wykonania. Na tej podstawie generator buduje kod CREATE TRIGGER w składni wybranej bazy. Narzędzie nie łączy się z żadną bazą: składa tekst polecenia, który kopiujesz albo pobierasz jako plik .sql i uruchamiasz w swoim kliencie SQL lub migracji.

Treść wpisujesz bez BEGIN i END, bo generator dodaje je sam; brakujący średnik na końcu ostatniej linii też jest uzupełniany. Dla MySQL nazwy trafiają w odwrotne apostrofy, a kod dostaje klauzulę FOR EACH ROW, blok BEGIN … END i opcjonalnie polecenia DELIMITER. Dla PostgreSQL powstają dwie instrukcje: funkcja fn_nazwa() zwracająca typ trigger w języku plpgsql oraz CREATE TRIGGER z EXECUTE FUNCTION. Jeśli treść nie zawiera RETURN, generator dopisuje właściwy zwrot: RETURN NEW dla BEFORE INSERT/UPDATE, RETURN OLD dla BEFORE DELETE i RETURN NULL dla AFTER oraz wyzwalaczy FOR EACH STATEMENT.

Po wygenerowaniu narzędzie analizuje treść i ostrzega przed typowymi błędami: odwołaniem do OLD w INSERT lub do NEW w DELETE, zmianą NEW w AFTER, próbą zmiany OLD, modyfikacją tabeli, na której działa wyzwalacz, zbędnym BEGIN/END w polu treści i liniami bez średnika. Do wyboru są cztery gotowe przykłady: znacznik czasu, audyt usunięć, stany magazynowe i walidacja ceny, każdy w wersji dla obu baz.

Przykład krok po kroku

1. Wybierz bazę danych MySQL / MariaDB.
2. Podaj nazwę tabeli: users.
3. Ustaw moment BEFORE i zdarzenie UPDATE.
4. Wpisz nazwę wyzwalacza: update_timestamp.
5. W polu treści wpisz: SET NEW.updated_at = NOW();
6. Zostaw zaznaczoną opcję DELIMITER i kliknij „Generuj SQL”.

Wynik ma 10 linii i nadaje się do wklejenia w konsoli mysql:

DELIMITER $$

CREATE TRIGGER `update_timestamp`
BEFORE UPDATE ON `users`
FOR EACH ROW
BEGIN
    SET NEW.updated_at = NOW();
END$$

DELIMITER ;

Po przełączeniu na PostgreSQL treść przykładu zmienia się na NEW.updated_at := NOW();, a kod ma 14 linii:

CREATE OR REPLACE FUNCTION fn_update_timestamp()
RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
    NEW.updated_at := NOW();
    RETURN NEW;
END;
$$;

CREATE TRIGGER update_timestamp
BEFORE UPDATE ON users
FOR EACH ROW
EXECUTE FUNCTION fn_update_timestamp();

Gdy kod MySQL trafia do aplikacji (PDO, DB::unprepared() w Laravelu), odznacz DELIMITER: to polecenie klienta mysql, a nie serwera, więc wysłane przez sterownik kończy się błędem składni.

Parametry generatora i ich wpływ na wynik

Praktyczne wskazówki

• Testuj na kopii bazy: wygenerowany trigger uruchom najpierw w środowisku testowym.
• Nazywaj opisowo. Nazwa wyzwalacza powinna odzwierciedlać tabelę i operację, np. users_before_update_timestamp, co ułatwia późniejsze zarządzanie.
• MySQL od wersji 5.7.2 pozwala na kilka triggerów BEFORE UPDATE na jednej tabeli; kolejność ustala się klauzulą FOLLOWS lub PRECEDES, której generator nie dodaje. PostgreSQL uruchamia takie wyzwalacze w kolejności alfabetycznej nazw.
• W PostgreSQL ponowne uruchomienie kodu podmieni funkcję (CREATE OR REPLACE FUNCTION), ale CREATE TRIGGER zgłosi błąd, gdy wyzwalacz już istnieje. Zaznacz wtedy opcję DROP TRIGGER IF EXISTS.

Ograniczenia narzędzia

• Brak pełnej walidacji składni: generator sprawdza nazwy i ostrzega przed typowymi błędami, ale nie parsuje treści, więc literówka w SQL wyjdzie dopiero w bazie.
• Nie obsługuje zaawansowanych klauzul, takich jak WHEN, REFERENCING czy FOLLOWS, ani wyzwalaczy INSTEAD OF i TRUNCATE; generuje podstawową postać.
• Nie zarządza uprawnieniami: nie dodaje klauzuli DEFINER ani nie sprawdza, czy użytkownik ma prawo utworzyć trigger (w MySQL potrzebne jest uprawnienie TRIGGER do tabeli).
• Nie zna stanu Twojej bazy, więc nie wykryje, że wyzwalacz o tej nazwie już istnieje. Przed konfliktem chronią opcje DROP TRIGGER IF EXISTS i IF NOT EXISTS.

Kiedy generator wyzwalacza SQL okazuje się przydatny

• Migracja logiki z aplikacji do bazy: gdy przenosisz reguły biznesowe z kodu do warstwy danych, szybko tworzysz szkielety triggerów dla wielu tabel.
• Nauka różnic między bazami. Przełączając MySQL i PostgreSQL na tym samym przykładzie, widzisz, czym różni się przypisanie do NEW (SET NEW.x = … kontra NEW.x := …), zgłaszanie błędu (SIGNAL kontra RAISE EXCEPTION) i dlaczego PostgreSQL wymaga funkcji.
• Prototypowanie i testy integracyjne: w kontenerze bazy potrzebujesz triggera, który rejestruje zmiany. Przykład „Audyt usunięć” zapisuje id usuniętego wiersza do tabeli audit_log, którą trzeba wcześniej utworzyć.

Najczęstsze błędy przy generowaniu i wdrażaniu triggerów

Jednym z najczęstszych problemów jest pominięcie zmiany separatora w konsoli mysql. Bez polecenia DELIMITER klient potraktuje średnik wewnątrz bloku BEGIN...END jako koniec instrukcji i przerwie wykonywanie; generator dodaje DELIMITER $$, a na końcu przywraca domyślny separator. Odwrotny błąd to wysyłanie DELIMITER przez PDO lub inny sterownik, który tego polecenia nie zna. Drugi błąd to mieszanie dialektów: SET NEW.kolumna = … i SIGNAL działają w MySQL, a w PostgreSQL potrzebne są NEW.kolumna := … i RAISE EXCEPTION.

Kolejny częsty błąd to próba modyfikacji wartości NEW w triggerze AFTER UPDATE. MySQL zgłasza wtedy błąd, a w PostgreSQL zmiana przechodzi bez skutku, bo wiersz jest już zapisany — kolumny ustawiaj wyłącznie w BEFORE. W PostgreSQL wyzwalacz BEFORE, który zwraca NULL zamiast NEW, po cichu pomija zapis wiersza. Nie ignoruj też wydajności: trigger FOR EACH ROW wykonuje się dla każdego wiersza, więc przy imporcie dużego zbioru może znacznie wydłużyć operację. W PostgreSQL wyzwalacz można na czas migracji wyłączyć (ALTER TABLE … DISABLE TRIGGER), w MySQL trzeba go usunąć i utworzyć ponownie.