V minulém dílu jsme si řekli dost o teorii triggerů, takže je čas podívat se na to, jak je můžeme v MySQL použít v praxi. Na jednu stranu to bude trochu smutné čtení, protože MySQL triggery zdaleka neumějí to, co triggery třebas ve Firebirdu. Na druhou stranu je ale i tak život se spouštěmi veselejší než bez nich.

Triggery v praxi

Uvedli jsme, že triggery mohou přispívat k bezpečnosti dat a že jedním z příkladů může být "bezpečné" mazání řádků v tabulce. Bezpečné proto, že záznam není vymazán úplně, ale data jsou přesunuta do jiné tabulky, takže je později lze dohledat. Pokud tedy budeme mít následující tabulku:

S testovacími daty:

můžeme chtít místo mazání z této tabulky data přesunout do "záložní" tabulky s tím, že si zároveň poznamenáme, kdo a kdy ta původní data promazával. Něco takového zcela určitě můžeme svěřit triggeru. Vytvoříme si tabulku, která bude obsahovat data z původní tabulky a ještě údaj o "mazajícím" uživateli a čase, kdy se řádky odstraňovaly:

a konečně, vytvoříme trigger, který při odstraňování dat ta původní data uchová v tabulkce bezpecna_zaloha:

Jaký je význam toho všeho? Výsledek spočívá v tom, že když se nyní pokusíte odstranit nějaká ta data z tabulky bezpecna, tak... vyzkoušejte postupně tyto příkazy:

Jak vidíte, smazaná data se objeví v tabulkce bezpecna_zaloha. K tomu všemu bude jistě vhodné uvést pár poznámek:

1. Trigger se tvoří pomocí příkazu CREATE TRIGGER.
2. Jméno triggeru musí být pro danou databázi jedinečné. To znamená, že nelze mít dva shodně pojmenované triggery ani na dvou různých tabulkách. Zvykl jsem si názvy triggerů začínat písmeny tr, abych je na první pohled odlišil od jiných objektů v databázi (jako jsou uložené procedury).
3. U každého triggeru musí být uvedeno, před nebo po jaké akci je spuštěn. Možnosti jsou BEFORE INSERT, BEFORE UPDATE, BEFORE DELETE, AFTER INSERT, AFTER UPDATE, AFTER DELETE. V MySQL navíc platí omezení, že pro každou z vyjmenovaných akcí smí existovat nejvýše jeden trigger. To mě trochu mrzí, protože v praxi někdy bývá zapotřebí provést více souvisejících akcí a nejpřehlednější by bylo umístit tyto akce do samostatných triggerů. Aby těch omezení nebylo málo, neumožňuje MySQL definovat jeden trigger pro dvě akce najednou, což je v jiných databázích obvyklé.
   
4. Každý trigger musí souviset právě s jednou tabulkou. V našem případě souvisí s tabulkou bezpecna. Mimochodem - jestliže je tabulka odstraněna, jsou odstraněny i všechny související triggery.
5. Tělo spouště v MySQL začíná klauzulí FOR EACH ROW a ta značí, že následující akce bude provedena tolikrát, kolik je řádků ovlivněných akčním dotazem. Většinou předem nevíte, kolik řádků bude ovlivněno, takže byste neměli spoléhat na to, zda a kolikrát bude tělo triggeru provedeno.
6. Jak jsem uvedl již v minulém díle seriálu, triggery mají přístup k měněným datům. Ten je reprezentován virtuálními tabulkami old a new. Jejich význam je ten, že tabulka old obsahuje původní data (ta, která se mají mazat pomocí DELETE nebo ta, která se upravují pomocí UPDATE) a tabulka new obsahuje konečná data (ta, která se vkládají pomocí INSERT nebo ta, která budou v tabulce po provedení UPDATE). My jsme v příkladu právě toho využili a data "schovali" do jiné tabulky.
7. Konečně, v triggeru lze využít i vestavěných funkcí. My jsme použili jednu funkci vracející současný čas a další vracející právě aktivního uživatele. Díky tomu máme kompletní přehled o tom, kdo a kdy data měnil.

K příkladu ještě jedno varování: Trigger se NESPUSTÍ při použití příkazu TRUNCATE TABLE. To není chyba, ale vlastnost DMBS, takže pokud se spoléháte na nějakou akci, která se spustí při odstraňování dat z tabulky, buďte opatrní. Při použití DELETE FROM TABLE se však trigger spustí a zpracuje všechny řádky, které ještě v nebohé tabulce zbývají.

Triggery jako kontrola dat

Další typickou činností triggerů je kontrola měněných dat. Mělo by tedy jít například napsat trigger, který do naší tabulky zakáže vkládat platy vyšší než 30000,- Kč. Vypadal by nějak takhle:

Bohužel, v době psaní tohoto článku je prakticky nemožné vyhodit nějakou smysluplnou chybu z triggeru, a to jejich použití pro kontrolu dat téměř znemožňuje. Pro informaci se můžete podívat do diskuse k tomuto tématu. Manuál doporučuje pro takový případ "uměle" vytvořit například chybu porušení primárního klíče, podle mě je to však jen chabá náplast. Problém je reportován do buglistu (sem a sem), tak uvidíme, co s tím bude vývojářský tým dělat.