Statement-level trigger — INSERT, UPDATE, DELETE yoki ayrim DDL statement bajarilganda ta’sirlangan satrlar sonidan qat’i nazar bir marta ishga tushadigan triggerdir. U batch audit, umumiy summary yoki statement kontekstini qayd etishda row-level triggerga qaraganda samaraliroq bo‘lishi mumkin.
Chaqiruv semantikasi
UPDATE orders SET status='archived' WHERE created_at < ... million satrni o‘zgartirsa statement trigger bir marta ishlaydi. Hech bir satr mos kelmasa ham ayrim database uni chaqiradi. Shu sabab “trigger ishladi” degani data o‘zgardi degani emas; affected count yoki transition table tekshiriladi.
Statement trigger OLD va NEW nomli bitta satrga ega emas. U statement metadata, session context va ayrim platformalarda transition table orqali barcha ta’sirlangan satrlarga kiradi.
Transition table
Transition table update’dan oldingi va keyingi row to‘plamini relation sifatida beradi. Trigger set-based SQL bilan audit yoki summary yaratadi:
old_rows: statementdan oldingi satrlar
new_rows: statementdan keyingi satrlar
Set-based join row triggerdagi N ta alohida queryni bitta operatsiyaga aylantiradi. Ammo million satrli transition table memory yoki temporary disk talab qiladi. Statement hajmi cheklanadi yoki batchlarga bo‘linadi.
Audit
Statement-level audit user, vaqt, SQL operation, table va affected countni bir yozuvda saqlaydi. Bu har row qiymatini ko‘rsatmaydi. Compliance har bir field change’ni talab qilsa transition table’dan detail audit yaratiladi yoki logical change log ishlatiladi.
SQL text sensitive literal saqlashi mumkin. Auditda parameter va secretlar sanitization qilinadi. Actor session contexti connection poolda keyingi requestga sizib o‘tmasligi uchun transaction boshida o‘rnatilib, yakunda tozalanadi.
Summary yangilash
Batch update’dan keyin summary table’ni yangi/old to‘plam farqi bilan bir marta yangilash mumkin. Bu hot counterga minglab update yuborishni kamaytiradi. Delta hisobida insert, delete va group key o‘zgargan update alohida ko‘riladi.
Summary xatosi asosiy statementni rollback qiladi, chunki trigger transaction ichida. Qimmat qayta hisoblashni async refreshga berish write latencyni kamaytiradi, lekin freshness lagini qabul qiladi.
BEFORE va AFTER
BEFORE statement trigger rowlar o‘zgarmasdan oldin umumiy setup yoki permission check bajarishi mumkin. U individual NEW qiymatni ko‘rmaydi. AFTER statement trigger barcha row operatsiyalari tugagach ishlaydi va final to‘plamni tahlil qiladi.
Deferred constraintlar hali commitda tekshirilishi mumkin. AFTER statement muvaffaqiyatli ishlasa ham transaction keyin constraint xatosi bilan rollback bo‘lishi mumkin. Tashqi side effect trigger ichida bajarilmaydi.
Row trigger bilan tartib
Odatda BEFORE statement, har row uchun BEFORE/AFTER, so‘ng AFTER statement ketma-ketligi mavjud, ammo aniq ordering enginega bog‘liq. Cascade va boshqa table triggerlari qo‘shimcha chaqiruvlar yaratadi.
Bir xil tableda ko‘p trigger bo‘lsa explicit dependency hujjatlashtiriladi. Trigger nomiga tayangan ordering platformalar oralig‘ida ko‘chishda buzilishi mumkin.
DDL va event trigger
Ayrim database schema change uchun statement yoki event trigger beradi. CREATE TABLE, ALTER yoki DROP audit va policy tekshiruviga tushadi. Migration tool ko‘p DDLni transaction ichida yuborsa event payload va rollback semantikasi tekshiriladi.
DDL trigger administratorni butunlay bloklab qo‘ymasligi uchun break-glass va recovery yo‘li mavjud bo‘ladi. Schema registry yoki migration history odatda yanada aniq boshqaruv manbai hisoblanadi.
Bog‘liq tushunchalar
Database trigger, Row-level trigger, Transition table, Audit, AFTER trigger, DDL trigger, Set-based operation