Risiko, Limitasi, dan Best Practice Trigger

1. Latar Belakang

Setelah empat hari mempelajari trigger mulai dari konsep, struktur, audit trail, hingga validasi dan otomasi, kini saatnya kita melihat sisi lain dari trigger. Seperti pisau bermata dua, trigger sangat powerful tapi juga punya risiko dan keterbatasan.

Mengapa Kita Perlu Membahas Risiko?

"Dengan kekuatan besar, datang tanggung jawab besar" - Uncle Ben, Spiderman

Trigger yang digunakan tanpa pemikiran matang bisa menyebabkan:

Database lemot karena terlalu banyak trigger
Bug susah dilacak karena logika tersembunyi
Kode sulit dipelihara karena trigger tersebar di mana-mana
Aplikasi crash tanpa pesan error yang jelas
Data inconsistency karena trigger yang salah urutan

Tujuan Hari Ini:

Memahami risiko dan limitasi trigger
Belajar best practice penggunaan trigger
Mengetahui kapan HARUS pakai trigger dan kapan JANGAN
Mampu mendokumentasikan dan mengelola trigger dengan baik

2. Alat dan Bahan

a. Perangkat Lunak

MySQL - Database dengan trigger yang sudah ada
Database plc_trigger_practice - Untuk studi kasus
MySQL Workbench / phpMyAdmin - Untuk menjalankan query
VS Code - Untuk dokumentasi

b. Perangkat Keras

Laptop/PC dengan spesifikasi standar

3. Pembahasan

3.1 Risiko Utama Penggunaan Trigger

RISIKO 1: Hidden Logic (Logika Tersembunyi)

Masalah: Trigger membuat logika bisnis "tersembunyi" di dalam database. Developer baru yang join project mungkin tidak tahu ada trigger di database.

Ilustrasi:

-- Developer A melihat query ini:
UPDATE karyawan SET gaji = 10000000 WHERE id = 1;

-- Dia kira cuma update biasa, tapi sebenarnya:
-- 🔥 TRIGGER 1: validasi_gaji_sebelum_update (jalan)
-- 🔥 TRIGGER 2: catat_perubahan_gaji (jalan)
-- 🔥 Mungkin ada trigger lain yang jalan!

-- Developer A bingung: "Kok tiba-tiba error? Kok ada data masuk ke log_gaji?"

Dampak:

Debugging jadi sulit
Onboarding developer baru lama
Perubahan kode berisiko tinggi

Contoh dari database kita:
Tanpa melihat daftar trigger, developer tidak akan tahu bahwa:

UPDATE karyawan akan memicu 2 trigger (validasi + audit)
INSERT INTO orders akan memicu 2 trigger (cek stok + kurangi stok + log)
UPDATE peminjaman akan memicu validasi pengembalian + update stok

RISIKO 2: Cascading Effect (Efek Domino)

Masalah: Satu trigger bisa memicu trigger lain, yang memicu trigger lain lagi, menciptakan rantai yang susah dilacak.

Ilustrasi:

-- Trigger A (ON tabel1) → UPDATE tabel2
-- Trigger B (ON tabel2) → INSERT tabel3  
-- Trigger C (ON tabel3) → DELETE tabel4
-- ... dan seterusnya

-- Satu INSERT di tabel1 bisa menyebabkan PULUHAN operasi di belakang layar!

Contoh di database kita (sederhana):

INSERT INTO orders 
    ↓
Trigger: cek_stok_sebelum_order (BEFORE)
    ↓ (lolos)
INSERT ke orders
    ↓
Trigger: kurangi_stok_saat_order (AFTER)
    ↓
- UPDATE products (stok berkurang)
- INSERT INTO log_stok
    ↓
Trigger: peringatan_stok_menipis (AFTER UPDATE ON products)
    ↓ (jika stok <5)
INSERT INTO notifikasi

Satu INSERT di orders bisa menghasilkan:

1 operasi INSERT (orders)
1 operasi UPDATE (products)
2 operasi INSERT (log_stok dan mungkin notifikasi)
Total: 4 operasi database!

RISIKO 3: Performa Menurun (Performance Hit)

Masalah: Trigger menambah beban database. Setiap operasi yang memicu trigger jadi lebih lambat.

Analogi:

🚗 Mobil biasa (tanpa trigger): 0-100 km/jam dalam 5 detik
🚌 Mobil dengan 5 trigger: 0-100 km/jam dalam 20 detik (karena berhenti di 5 pos pemeriksaan)

Perbandingan:

Operasi	Tanpa Trigger	Dengan 1 Trigger	Dengan 3 Trigger
INSERT 1000 baris	0.5 detik	1 detik	2 detik
UPDATE 1000 baris	0.3 detik	0.8 detik	1.8 detik
DELETE 1000 baris	0.2 detik	0.5 detik	1.2 detik

Di database kita, operasi yang berat:

UPDATE karyawan → validasi kompleks (5 aturan) + audit trail
INSERT orders → 2 trigger dengan SELECT ke tabel lain
UPDATE peminjaman → validasi + hitung denda + update stok

RISIKO 4: Debugging yang Sulit

Masalah: Error di trigger susah dilacak karena tidak ada stack trace yang jelas seperti di aplikasi.

Contoh:

-- Developer menjalankan query:
UPDATE karyawan SET gaji = 35000000 WHERE id = 2;

-- ERROR: Gaji manager gaboleh lebih gede dari direktur!

-- Pertanyaan:
-- ❌ Trigger mana yang error?
-- ❌ Aturan mana yang dilanggar?
-- ❌ Data apa yang menyebabkan error?
-- ❌ Bagaimana cara fix-nya?

-- Developer harus buka kode trigger dan baca satu per satu!

Bandingkan dengan error di aplikasi:

// Error di Node.js/Express:
Error: Gaji manager gaboleh lebih gede dari direktur!
    at validateGaji (validators/gaji.validator.js:25:11)
    at updateKaryawan (services/karyawan.service.js:48:5)
    at controller (controllers/karyawan.controller.js:12:3)
    
// ✅ JELAS! Langsung tahu dimana errornya!

RISIKO 5: Portability Issues (Masalah Migrasi Database)

Masalah: Sintaks trigger berbeda-beda di tiap database. Pindah dari MySQL ke PostgreSQL bisa jadi mimpi buruk.

Perbandingan Sintaks:

Aspek	MySQL	PostgreSQL	Oracle
Delimiter	`DELIMITER $$`	Tidak perlu	Tidak perlu
Variable	`DECLARE var INT`	`DECLARE var INTEGER;`	`var NUMBER;`
Assign	`SET var = 1`	`var := 1`	`var := 1`
Error	`SIGNAL SQLSTATE`	`RAISE EXCEPTION`	`RAISE_APPLICATION_ERROR`

Dampak:

Migrasi database butuh rewrite semua trigger
Lock-in ke satu vendor database
Susah pindah ke cloud database lain

RISIKO 6: Recursive Trigger (Trigger Rekursif)

Masalah: Trigger bisa memanggil dirinya sendiri jika tidak hati-hati, menyebabkan infinite loop.

Contoh:

-- ❌ SALAH: Trigger rekursif
CREATE TRIGGER update_stok
AFTER UPDATE ON products
FOR EACH ROW
BEGIN
    -- Ini akan memicu dirinya sendiri lagi!
    UPDATE products SET updated_at = NOW() WHERE id = NEW.id;
END;

-- 🔥 Loop tak berujung!

Di database kita, kita hindari rekursif dengan:

Trigger hanya update tabel LAIN, bukan tabel sendiri
Kalau harus update tabel sendiri, pakai BEFORE trigger

RISIKO 7: Transaction dan Rollback Issues

Masalah: Trigger jalan dalam transaksi yang sama. Jika trigger error, SEMUA operasi dibatalkan.

Contoh:

START TRANSACTION;

INSERT INTO orders ... -- (1) Order masuk
-- 🔥 Trigger error: Stok tidak cukup!
-- SEMUA dibatalkan! 

-- Order batal, user harus input ulang dari awal
ROLLBACK;

Dampak di aplikasi:

User bisa frustrasi karena harus input ulang
Aplikasi harus handle error dengan baik
Bisa loss data jika tidak handle transaksi dengan benar

RISIKO 8: Ketergantungan Tersembunyi (Hidden Dependencies)

Masalah: Trigger bisa membuat ketergantungan antar tabel yang tidak terlihat di skema database.

Contoh:

-- Tabel orders bergantung pada products (foreign key)
-- Tapi juga bergantung pada:
-- - log_stok (trigger insert)
-- - notifikasi (trigger update products)
-- - Dan mungkin tabel lain!

-- Developer drop tabel log_stok? 
-- 💥 Trigger error! Semua order gagal!

RISIKO 9: Over-Engineering (Kebanyakan Trigger)

Masalah: Semua logic dimasukkan ke trigger, padahal mungkin lebih cocok di aplikasi.

Tanda-tanda Over-Engineering:

Ada >10 trigger di database
Trigger berisi >100 baris kode
Trigger melakukan kalkulasi kompleks
Trigger memanggil tabel lain berkali-kali

Di database kita, kita punya 11 trigger. Apakah ini over-engineering?

✅ E-commerce: 3 trigger (wajar)
✅ Karyawan: 3 trigger (wajar)
✅ Perpustakaan: 4 trigger (wajar)
✅ Total 11 trigger untuk 3 modul terpisah → MASIH WAJAR

3.2 Limitasi Trigger

Selain risiko, trigger juga punya batasan teknis:

LIMITASI 1: Tidak Bisa Mengembalikan Hasil (Result Set)

Trigger tidak bisa mengembalikan data seperti SELECT. Trigger hanya bisa:

Melakukan operasi data (INSERT/UPDATE/DELETE)
Membatalkan operasi (SIGNAL)
Tidak bisa mengirim data ke aplikasi

LIMITASI 2: Tidak Bisa Memanggil Prosedur Eksternal

Trigger hanya bisa menjalankan SQL di database yang sama. Tidak bisa:

Memanggil API eksternal
Mengirim email
Menulis file di server
Berkomunikasi dengan service lain

Contoh yang TIDAK BISA dilakukan trigger:

-- ❌ Tidak bisa kirim email
CALL send_email('user@email.com', 'Order berhasil');

-- ❌ Tidak bisa panggil API
CALL http_post('https://api.example.com/notify');

-- ❌ Tidak bisa baca file
SELECT * FROM EXTERNAL_FILE('/data/file.txt');

LIMITASI 3: Keterbatasan Debugging

MySQL tidak punya debugger untuk trigger. Cara debug hanya:

SELECT statement (tapi hasilnya tidak bisa dilihat langsung)
Insert ke tabel log sementara
Trial and error

LIMITASI 4: Tidak Bisa Menggunakan Prepared Statements

Trigger tidak bisa menggunakan prepared statements dengan parameter dinamis.

LIMITASI 5: Keterbatasan Recursive

MySQL punya batasan max_sp_recursion_depth untuk mencegah rekursi tak terbatas.

3.3 Best Practice Penggunaan Trigger

Setelah memahami risiko dan limitasi, berikut panduan penggunaan trigger yang baik:

BEST PRACTICE 1: Dokumentasikan Semua Trigger!

Buat file dokumentasi seperti ini:

-- =====================================================
-- DATABASE: plc_trigger_practice
-- FILE    : dokumentasi_trigger.sql
-- AUTHOR  : Tim Database
-- DATE    : 2026-02-19
-- =====================================================

-- =====================================================
-- MODUL 1: E-COMMERCE
-- =====================================================

/**
 * TRIGGER: cek_stok_sebelum_order
 * TABEL  : orders
 * EVENT  : BEFORE INSERT
 * FUNGSI : Validasi stok sebelum order masuk
 * 
 * DETAIL:
 * 1. Cek stok produk cukup (tidak boleh kurang dari jumlah order)
 * 2. Cek jumlah order > 0
 * 3. Hitung total harga otomatis
 * 4. Set default customer name jika kosong
 * 
 * DEPENDENCIES:
 * - Tabel products (SELECT stok, harga)
 * 
 * ERROR MESSAGES:
 * - 'Stok tidak cukup, bro!'
 * - 'Jumlah order harus lebih dari 0!'
 * 
 * LAST UPDATED: 2026-02-18
 */

/**
 * TRIGGER: kurangi_stok_saat_order
 * TABEL  : orders
 * EVENT  : AFTER INSERT
 * FUNGSI : Kurangi stok produk dan catat log
 * 
 * DETAIL:
 * 1. Update stok produk (stok - jumlah order)
 * 2. Update terjual produk (terjual + jumlah order)
 * 3. Insert ke log_stok
 * 
 * DEPENDENCIES:
 * - Tabel products (UPDATE)
 * - Tabel log_stok (INSERT)
 * 
 * LAST UPDATED: 2026-02-18
 */

-- =====================================================
-- MODUL 2: HRD (KARYAWAN)
-- =====================================================

/**
 * TRIGGER: validasi_gaji_sebelum_update
 * TABEL  : karyawan
 * EVENT  : BEFORE UPDATE
 * FUNGSI : Validasi aturan penggajian
 * 
 * ATURAN:
 * 1. Kenaikan gaji maksimal 20%
 * 2. Gaji manager ≤ gaji direktur
 * 3. Gaji staff ≤ 80% gaji manager departemen sama
 * 4. Gaji tidak boleh turun jika jabatan sama
 * 5. Total gaji departemen ≤ budget (100jt)
 * 
 * DEPENDENCIES:
 * - Tabel karyawan (SELECT untuk cek gaji direktur/manager)
 * 
 * ERROR MESSAGES:
 * - '❌ Kenaikan gaji maksimal 20% aja, santuy!'
 * - '❌ Gaji manager gaboleh lebih gede dari direktur!'
 * - '❌ Gaji staff maksimal 80% dari gaji manager di departemen yang sama!'
 * - '❌ Gaji tidak boleh turun jika jabatan sama!'
 * - '❌ Total gaji departemen melebihi budget!'
 * 
 * LAST UPDATED: 2026-02-18
 */

BEST PRACTICE 2: Beri Nama Trigger yang Jelas

Format penamaan yang baik:

[aksi]_[tabel]_[timing].sql

Contoh di database kita:

Nama Trigger	Arti
`cek_stok_sebelum_order`	Cek stok, sebelum order, untuk INSERT
`kurangi_stok_saat_order`	Kurangi stok, saat order (AFTER), untuk INSERT
`validasi_gaji_sebelum_update`	Validasi gaji, sebelum UPDATE
`catat_perubahan_gaji`	Catat perubahan gaji, AFTER UPDATE

BEST PRACTICE 3: Jaga Trigger Tetap Sederhana

✅ Trigger yang baik:

Maksimal 20-30 baris
Satu tujuan jelas
Tidak melakukan kalkulasi rumit
Hanya akses 1-2 tabel lain

❌ Trigger yang buruk:

Ratusan baris
Banyak nested IF
Kalkulasi kompleks
Akses banyak tabel

Contoh trigger sederhana yang baik:

CREATE TRIGGER kurangi_stok_saat_order
AFTER INSERT ON orders
FOR EACH ROW
BEGIN
    UPDATE products 
    SET stok = stok - NEW.jumlah
    WHERE id = NEW.product_id;
END;

BEST PRACTICE 4: Batasi Jumlah Trigger per Tabel

Rekomendasi:

Maksimal 3 trigger per tabel
1 untuk validasi (BEFORE INSERT/UPDATE)
1 untuk audit trail (AFTER INSERT/UPDATE/DELETE)
1 untuk otomasi (AFTER)

Di database kita:

Tabel	Jumlah Trigger	Status
orders	2	✅ OK
products	2	✅ OK
karyawan	3	✅ OK
peminjaman	4	⚠️ Perlu dievaluasi

BEST PRACTICE 5: Gunakan SIGNAL dengan Pesan Jelas

-- ❌ Buruk
SIGNAL SQLSTATE '45000';

-- ✅ Baik
SIGNAL SQLSTATE '45000' 
SET MESSAGE_TEXT = 'Stok tidak cukup untuk produk ini! Tersedia: 5, diminta: 10';

-- ✅ Sangat Baik (dengan informasi lengkap)
IF stok_tersedia < NEW.jumlah THEN
    SIGNAL SQLSTATE '45000' 
    SET MESSAGE_TEXT = CONCAT(
        'Stok tidak cukup! ',
        'Produk: ', (SELECT nama FROM products WHERE id = NEW.product_id),
        ', Stok: ', stok_tersedia,
        ', Diminta: ', NEW.jumlah
    );
END IF;

BEST PRACTICE 6: Pertimbangkan Performa

Hindari SELECT berulang di trigger:

-- ❌ Buruk: SELECT setiap baris
FOR EACH ROW
BEGIN
    SELECT stok INTO stok_lama FROM products WHERE id = NEW.product_id;
    -- operasi lain
    SELECT harga INTO harga FROM products WHERE id = NEW.product_id;
    -- operasi lain lagi
END;

-- ✅ Baik: SELECT sekali untuk semua kebutuhan
FOR EACH ROW
BEGIN
    SELECT stok, harga INTO stok_lama, harga
    FROM products 
    WHERE id = NEW.product_id;
    
    -- Pakai stok_lama dan harga untuk operasi berikutnya
END;

BEST PRACTICE 7: Test Semua Skenario

Buat test case untuk setiap trigger:

-- Test validasi_gaji_sebelum_update

-- Test 1: Kenaikan wajar (seharusnya BERHASIL)
UPDATE karyawan SET gaji = 10000000 WHERE id = 1;

-- Test 2: Kenaikan terlalu tinggi (seharusnya ERROR)
UPDATE karyawan SET gaji = 20000000 WHERE id = 1;

-- Test 3: Manager minta gaji lebih dari direktur (seharusnya ERROR)
UPDATE karyawan SET gaji = 50000000 WHERE id = 2;

-- Test 4: Staff minta gaji di atas 80% manager (seharusnya ERROR)
UPDATE karyawan SET gaji = 15000000 WHERE id = 4;

BEST PRACTICE 8: Regular Review dan Maintenance

Jadwalkan review trigger secara berkala:

Bulanan: Cek log error terkait trigger
Kuartalan: Review performa trigger lambat
Tahunan: Audit semua trigger, hapus yang tidak dipakai

3.4 Kapan Pakai Trigger dan Kapan Jangan

✅ PAKAI TRIGGER KALO:

Situasi	Contoh	Kenapa
Audit Trail	Catat perubahan gaji, stok	Harus otomatis dan tidak bisa dilewati
Validasi Sederhana	Cek stok, cek umur minimal	Cepat, langsung di database
Maintain Data Integrity	Stok tidak boleh minus	Mencegah data rusak
Aturan Universal	Berlaku untuk semua aplikasi	Konsisten di semua platform
Operasi Atomic	Harus sukses semua atau batal	Transaksi database

❌ JANGAN PAKAI TRIGGER KALO:

Situasi	Contoh	Alternatif
Logika Kompleks	Menghitung pajak bertingkat	Backend / Stored Procedure
Butuh Data Eksternal	Validasi dengan API pihak ketiga	Backend
Sering Berubah	Aturan promo yang ganti tiap minggu	Backend / Config file
Butuh Notifikasi	Kirim email, WhatsApp, SMS	Backend + Message Queue
Debugging Intensif	Logic yang sering error	Backend (lebih mudah debug)
Business Logic Inti	Aturan bisnis utama aplikasi	Service Layer di backend

3.5 Matriks Keputusan: Trigger vs Backend

Kriteria	Trigger	Backend	Pilihan
Kecepatan eksekusi	✅ Cepat	❌ Lambat (network)	Trigger
Konsistensi multi-app	✅ Tinggi	❌ Beda app beda logic	Trigger
Mudah di-debug	❌ Sulit	✅ Mudah (stack trace)	Backend
Mudah diubah	❌ Susah (akses DB)	✅ Gampang (deploy)	Backend
Integrasi eksternal	❌ Tidak bisa	✅ Bisa (API, email)	Backend
Kompleksitas	❌ Terbatas	✅ Tinggi	Backend
Keamanan data	✅ Langsung	❌ Via aplikasi	Trigger

3.6 Studi Kasus: Analisis Trigger di Database Kita

Mari kita evaluasi setiap trigger di database kita berdasarkan best practice:

MODUL E-COMMERCE (✅ GOOD)

Trigger	Evaluasi	Rekomendasi
`cek_stok_sebelum_order`	✅ Sederhana, jelas, penting	Pertahankan
`kurangi_stok_saat_order`	✅ Sederhana, otomatis	Pertahankan
`peringatan_stok_menipis`	✅ Inovatif, membantu	Pertahankan

Kesimpulan: Modul e-commerce sudah sesuai best practice.

MODUL KARYAWAN (✅ GOOD, tapi ada catatan)

Trigger	Evaluasi	Rekomendasi
`cek_karyawan_sebelum_insert`	✅ Sederhana, jelas	Pertahankan
`validasi_gaji_sebelum_update`	⚠️ Agak kompleks (5 aturan)	Pertahankan tapi dokumentasi
`catat_perubahan_gaji`	✅ Audit trail penting	Pertahankan

Catatan: Trigger validasi_gaji_sebelum_update cukup kompleks. Pastikan:

Dokumentasi jelas
Test semua skenario
Review berkala

MODUL PERPUSTAKAAN (⚠️ PERLU EVALUASI)

Trigger	Evaluasi	Rekomendasi
`cek_stok_buku_sebelum_pinjam`	✅ Sederhana, jelas	Pertahankan
`kurangi_stok_buku_saat_pinjam`	✅ Sederhana	Pertahankan
`validasi_pengembalian_buku`	✅ Sederhana	Pertahankan
`tambah_stok_buku_saat_kembali`	✅ Sederhana	Pertahankan

Catatan: 4 trigger untuk satu tabel peminjaman cukup banyak. Tapi karena fungsinya jelas terpisah, masih bisa diterima.

4. Latihan Praktikum

Exercise 1: Analisis Risiko

Jalankan query berikut dan identifikasi risiko apa yang terjadi:

-- Skenario 1
INSERT INTO orders (product_id, jumlah) VALUES (999, 5);

-- Skenario 2
UPDATE karyawan SET gaji = 50000000 WHERE id = 2;

-- Skenario 3
DELETE FROM products WHERE id = 1;

Pertanyaan:

Apa yang terjadi di setiap skenario?
Risiko apa yang muncul?
Bagaimana cara memperbaikinya?

Exercise 2: Dokumentasi Trigger

Buat dokumentasi untuk trigger peringatan_stok_menipis dengan format:

/**
 * TRIGGER: [nama_trigger]
 * TABEL  : [nama_tabel]
 * EVENT  : [BEFORE/AFTER] [INSERT/UPDATE/DELETE]
 * FUNGSI : [deskripsi singkat]
 * 
 * DETAIL:
 * [daftar detail fungsi]
 * 
 * DEPENDENCIES:
 * [daftar tabel lain yang dipengaruhi/dibaca]
 * 
 * ERROR MESSAGES:
 * [daftar error yang mungkin muncul]
 * 
 * LAST UPDATED: [tanggal]
 */

Exercise 3: Refactor Trigger

Trigger validasi_gaji_sebelum_update cukup panjang. Coba refactor dengan memisahkan validasi ke dalam fungsi-fungsi terpisah:

-- Buat fungsi-fungsi validasi terpisah
CREATE FUNCTION cek_kenaikan_gaji(old_gaji DECIMAL, new_gaji DECIMAL) 
RETURNS BOOLEAN
BEGIN
    RETURN new_gaji <= old_gaji * 1.2;
END;

-- Panggil di trigger
IF NOT cek_kenaikan_gaji(OLD.gaji, NEW.gaji) THEN
    SIGNAL SQLSTATE '45000' 
    SET MESSAGE_TEXT = 'Kenaikan gaji maksimal 20%';
END IF;

Exercise 4: Redesign Trigger

Bayangkan kita ingin mengirim email notifikasi setiap kali ada order baru. Apakah trigger cocok? Jelaskan mengapa dan berikan alternatif solusi.

5. Daftar Pustaka

MySQL Documentation (n.d.). 27.3.1 Trigger Syntax and Examples. https://dev.mysql.com
MYSQL Tutorial (n.d.). MySQL Triggers. https://www.mysqltutorial.org
Devart (n.d.). Triggers in MySQL: Definition and How to Use them. https://www.devart.com
GeeksforGeeks (2025). SQL Create Trigger. https://www.geeksforgeeks.org
W3Resource (2022). MySQL Triggers. https://www.w3resource.com

Risiko, Limitasi, dan Best Practice Trigger - Perwira Learning Center

1. Latar Belakang

2. Alat dan Bahan

a. Perangkat Lunak

b. Perangkat Keras

3. Pembahasan

3.1 Risiko Utama Penggunaan Trigger

RISIKO 1: Hidden Logic (Logika Tersembunyi)

RISIKO 2: Cascading Effect (Efek Domino)

RISIKO 3: Performa Menurun (Performance Hit)

RISIKO 4: Debugging yang Sulit

RISIKO 5: Portability Issues (Masalah Migrasi Database)

RISIKO 6: Recursive Trigger (Trigger Rekursif)

RISIKO 7: Transaction dan Rollback Issues

RISIKO 8: Ketergantungan Tersembunyi (Hidden Dependencies)

RISIKO 9: Over-Engineering (Kebanyakan Trigger)

3.2 Limitasi Trigger

LIMITASI 1: Tidak Bisa Mengembalikan Hasil (Result Set)

LIMITASI 2: Tidak Bisa Memanggil Prosedur Eksternal

LIMITASI 3: Keterbatasan Debugging

LIMITASI 4: Tidak Bisa Menggunakan Prepared Statements

LIMITASI 5: Keterbatasan Recursive

3.3 Best Practice Penggunaan Trigger

BEST PRACTICE 1: Dokumentasikan Semua Trigger!

BEST PRACTICE 2: Beri Nama Trigger yang Jelas

BEST PRACTICE 3: Jaga Trigger Tetap Sederhana

BEST PRACTICE 4: Batasi Jumlah Trigger per Tabel

BEST PRACTICE 5: Gunakan SIGNAL dengan Pesan Jelas

BEST PRACTICE 6: Pertimbangkan Performa

BEST PRACTICE 7: Test Semua Skenario

BEST PRACTICE 8: Regular Review dan Maintenance

3.4 Kapan Pakai Trigger dan Kapan Jangan

✅ PAKAI TRIGGER KALO:

❌ JANGAN PAKAI TRIGGER KALO:

3.5 Matriks Keputusan: Trigger vs Backend

3.6 Studi Kasus: Analisis Trigger di Database Kita

MODUL E-COMMERCE (✅ GOOD)

MODUL KARYAWAN (✅ GOOD, tapi ada catatan)

MODUL PERPUSTAKAAN (⚠️ PERLU EVALUASI)

4. Latihan Praktikum

Exercise 1: Analisis Risiko

Exercise 2: Dokumentasi Trigger

Exercise 3: Refactor Trigger

Exercise 4: Redesign Trigger

5. Daftar Pustaka

Diposting oleh Al Zaki Ibra Ramadani

Anda mungkin menyukai postingan ini

Posting Komentar

0 Komentar

Social Plugin

Most Popular

Recent Post

Popular Posts

Footer Menu Widget

Contact form