Anda menggunakan transaksi otonom untuk mengatasi fakta bahwa pemicu tidak dapat menanyakan tabelnya sendiri. Anda telah mengalami kesalahan tabel mutasi yang terkenal dan Anda telah menemukan bahwa mendeklarasikan pemicu sebagai transaksi otonom membuat kesalahan hilang.
Tidak beruntung untuk Anda, ini tidak menyelesaikan masalah sama sekali:
- Pertama, semua logika transaksi hilang. Anda tidak dapat mengembalikan perubahan pada
suscription_facttabel, mereka berkomitmen , sedangkan transaksi utama Anda tidak dan dapat dibatalkan. Jadi, Anda juga kehilangan integritas data Anda. - Pemicu tidak dapat melihat baris baru karena baris baru belum di-commit! Karena pemicu berjalan dalam transaksi independen, pemicu tidak dapat melihat perubahan tanpa komitmen yang dibuat oleh transaksi utama:Anda akan mendapatkan hasil yang sepenuhnya salah.
Inilah sebabnya mengapa Anda tidak boleh melakukan logika bisnis apa pun dalam transaksi otonom. (ada aplikasi yang sah tetapi hampir seluruhnya terbatas pada logging/debugging).
Dalam kasus Anda, Anda harus:
- Perbarui logika Anda sehingga tidak perlu mengkueri tabel Anda (memperbarui
suscription_facthanya jika baris baru lebih baru daripada nilai lama yang disimpan diid_date_unsuscription). - Lupakan penggunaan logika bisnis di pemicu dan gunakan prosedur yang memperbarui semua tabel dengan benar atau gunakan tampilan karena di sini kita memiliki kasus data yang berlebihan.
- Gunakan solusi yang benar-benar berfungsi (oleh Tom Kyte) .
Saya akan sangat menyarankan menggunakan (2) di sini. Jangan gunakan pemicu untuk mengkode logika bisnis. Mereka sulit untuk ditulis tanpa bug dan lebih sulit lagi untuk dipertahankan. Menggunakan prosedur menjamin bahwa semua kode yang relevan dikelompokkan di satu tempat (paket atau prosedur), mudah dibaca dan diikuti dan tanpa konsekuensi yang tidak terduga.
