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:
create table bezpecna
(id int not null auto_increment, jmeno varchar( 50 ) not null, plat
decimal(12,4) not null, primary key (id)) type = myisam;
S testovacími daty:
insert into bezpecna
(jmeno, plat) values ('Jarda', 12000);
insert into bezpecna (jmeno, plat) values ('Pepa', 13000);
insert into bezpecna (jmeno, plat) values ('Franta', 14000);
insert into bezpecna (jmeno, plat) values ('Honza', 10000);
insert into bezpecna (jmeno, plat) values ('Anička', 11500);
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:
create table
bezpecna_zaloha like bezpecna;
alter table bezpecna_zaloha add column cas_odstraneni datetime;
alter table bezpecna_zaloha add column uzivatel varchar (128);
a konečně, vytvoříme trigger, který při odstraňování dat ta původní
data uchová v tabulkce bezpecna_zaloha:
create trigger
trSaveRows
before delete
on bezpecna
for each row
begin
insert into bezpecna_zaloha(id, jmeno, plat,
cas_odstraneni, uzivatel)
values (old.id, old.jmeno, old.plat, now(), user());
end;
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:
delete from bezpecna
where id > 2;
select * from bezpecna;
select * from bezpecna_zaloha;
Jak vidíte, smazaná data se objeví v tabulkce bezpecna_zaloha. K tomu všemu bude
jistě vhodné uvést pár poznámek:
- Trigger se tvoří pomocí příkazu CREATE
TRIGGER.
- 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).
- 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é.
- 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.
- 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.
- 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.
- 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:
create trigger trMaxPlat
before insert
on bezpecna
for each row
begin
if new.plat>30000 then /*něco, co akci zruší*/;
end if;
end;
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.