Pemicu SQL dan kapan atau kapan tidak menggunakannya.

Ketika saya awalnya belajar tentang SQL saya selalu diberitahu, hanya menggunakan pemicu jika Anda benar-benar perlu dan memilih untuk menggunakan prosedur tersimpan sebagai gantinya jika mungkin.

Sayangnya, pada saat itu (beberapa tahun yang lalu) saya tidak terlalu penasaran dan peduli dengan fundamental seperti saya sekarang jadi tidak pernah menanyakan alasannya.

Apa pendapat komunitas dalam hal ini? Apakah itu hanya preferensi pribadi seseorang, atau pemicunya harus dihindari (seperti kursor) kecuali ada alasan bagus untuknya.

The artikel Wikipedia pada database pemicu hadiah gambaran yang baik dari apa yang pemicu yang dan kapan harus menggunakannya dalam database yang berbeda.

Diskusi berikut ini hanya didasarkan pada SQL Server.

Menggunakan pemicu cukup valid ketika penggunaannya dibenarkan. Sebagai contoh, mereka memiliki nilai bagus dalam audit (menjaga riwayat data) tanpa memerlukan kode prosedural eksplisit dengan setiap perintah CRUD di setiap tabel.

Pemicu memberi Anda kontrol tepat sebelum data diubah dan tepat setelah data diubah. Ini memungkinkan untuk:

• Audit seperti yang disebutkan sebelumnya
• Pemeriksaan validasi dan keamanan bisnis jika diinginkan. Karena jenis kontrol ini, Anda dapat melakukan tugas-tugas seperti memformat kolom sebelum dan sesudah memasukkan ke dalam basis data.

Saya selalu diberitahu, hanya gunakan pemicu jika Anda benar-benar perlu dan memilih untuk menggunakan prosedur tersimpan sebagai gantinya jika mungkin.

Mungkin beberapa alasan untuk ini adalah:

1. Beberapa fungsi yang digunakan pemicu di masa lalu sekarang dapat dilakukan dengan cara lain seperti memperbarui total dan perhitungan otomatis pada kolom.
2. Anda tidak melihat di mana pemicu dipanggil dengan memeriksa kode saja tanpa mengetahui keberadaannya. Anda melihat efeknya ketika Anda melihat perubahan data dan kadang-kadang membingungkan untuk mencari tahu mengapa perubahan itu terjadi kecuali Anda tahu ada pemicu atau lebih banyak bertindak di atas meja.
3. Jika Anda menggunakan beberapa kontrol basis data seperti PERIKSA, RI, Pemicu pada beberapa tabel, aliran detail transaksi Anda menjadi rumit untuk dipahami dan dipelihara. Anda perlu tahu persis apa yang terjadi ketika. Sekali lagi, Anda akan memerlukan dokumentasi yang baik untuk ini.

Beberapa perbedaan antara pemicu dan prosedur tersimpan non-pemicu antara lain:

• Prosedur tersimpan non-pemicu seperti program yang harus dijalankan secara eksplisit baik dari kode atau dari penjadwal atau dari pekerjaan batch, dll. Untuk melakukan tugasnya, sedangkan pemicu adalah jenis khusus dari prosedur tersimpan yang dijalankan sebagai respons suatu peristiwa daripada langsung dieksekusi oleh pengguna. Acara tersebut dapat berupa perubahan data dalam kolom data misalnya.
• Pemicu memiliki tipe. Pemicu DDL dan Pemicu DML (dari jenis: BUKAN, Untuk, dan SETELAH)
• Prosedur Non-Trigger Stored dapat merujuk semua jenis objek, namun, untuk referensi tampilan, Anda harus menggunakan BUKAN pemicu.
• Dalam SQLServer, Anda dapat memiliki nomor apa pun pada prosedur tersimpan non-pemicu tetapi hanya 1 BUKAN pemicu per tabel.

Pemicu adalah persyaratan untuk aturan integritas data yang kompleks. Ini tidak dapat diberlakukan di mana pun kecuali database atau Anda akan memiliki masalah integritas data.

Mereka juga merupakan tempat terbaik untuk audit kecuali Anda tidak ingin menangkap semua perubahan pada database (yang merupakan masalah audit dari aplikasi).

Pemicu dapat menyebabkan masalah kinerja jika tidak ditulis dengan hati-hati dan tidak cukup banyak pengembang yang memiliki pengetahuan untuk menulisnya dengan baik. Ini adalah bagian dari tempat mereka mendapatkan rap buruk.

Pemicu sering kali lebih lambat daripada cara lain untuk menjaga integritas data, jadi jika Anda dapat menggunakan batasan pemeriksaan, gunakan itu alih-alih pemicu.

Sangat mudah untuk menulis pemicu buruk yang melakukan hal-hal bodoh seperti mencoba mengirim email. Apakah Anda benar-benar ingin tidak dapat mengubah catatan di db jika server email turun?

Di SQL server, pemicu beroperasi pada kumpulan catatan. Terlalu sering pengembang berpikir mereka hanya perlu menangani satu catatan sisipan, pembaruan atau penghapusan. Itu bukan satu-satunya jenis perubahan data yang terjadi pada basis data dan semua pemicu harus diuji dalam kondisi 1 perubahan catatan dan banyak perubahan catatan. Lupa melakukan tes kedua dapat menyebabkan pemicu yang berkinerja sangat buruk atau hilangnya integritas data.

Penggunaan pemicu basis data

1. Untuk mengarahkan nilai kolom secara otomatis.
2. Untuk menegakkan batasan integritas yang kompleks.
3. Untuk menegakkan aturan bisnis yang kompleks.
4. Untuk menyesuaikan otorisasi keamanan yang kompleks.
5. Untuk mempertahankan tabel replikasi.
6. Untuk mengaudit modifikasi data.

Kasus penggunaan lain yang secara pribadi saya temui adalah untuk database yang diakses oleh lebih dari satu program. Jika Anda ingin mengimplementasikan fungsionalitas tetapi tidak mendesain ulang semua sistem untuk itu, pemicu membuat solusi yang masuk akal.

Sebagai contoh, saya baru-baru ini bekerja pada database yang sebelumnya ada hanya sebagai sistem kantor. Ketika webapp ditulis untuk berinteraksi dengannya, kami ingin menerapkan sistem pemberitahuan (mirip dengan stackexchange, misalnya), yang akan diaktifkan oleh beberapa peristiwa, seperti memproses transaksi, dan sebagainya. Kami dapat menerapkan pemicu sehingga pembaruan di backend kantor mengeluarkan pemicu untuk membuat pemberitahuan untuk frontend dan memberi tahu pengguna bahwa transaksi mereka telah diproses oleh kantor.

Pemicu dapat digunakan untuk menegakkan batasan pada basis data yang tidak dapat ditegakkan selama pembuatan skema basis data dan pernyataan DML apa pun.

Katakanlah Anda perlu mendorong data ke sistem pihak ke-3 dalam waktu dekat. Tabel Anda berisi 950 gigabytes data, jadi terlalu besar untuk hanya mendorong seluruh tabel ke aplikasi pihak ke-3.

Alih-alih, Anda mengumpulkan perubahan dalam antrian. Beberapa program eksternal kemudian secara berkala akan mendorong keluar sejumlah kecil data yang antri.

Sistem ini memiliki lebih dari 2000 prosedur tersimpan. Anda juga tahu bahwa ada banyak sql dalam kode sumber. Untuk menjamin antrian diisi dengan benar, Anda harus mencari melalui semua procs dan kode yang disimpan dan berharap Anda tidak ketinggalan apa pun.

Alih-alih, Anda bisa meletakkan pemicu di atas meja agar antrian tetap diperbarui. Dijamin tidak ketinggalan apa-apa. Satu lokasi sentral. Penalti kinerja? Tidak juga karena klik mengisi antrian tidak dapat dihindari apakah itu oleh pemicu, atau eksternal.

Dalam skenario ini saya akan mengatakan tidak menggunakan pemicu adalah pilihan desain yang buruk. Jika nanti Anda ingin menggunakan metode baru untuk mendorong data (misalkan antrian tidak berfungsi) dan antarmuka berubah Anda dilindungi jika Anda menggunakan pelatuk. Pemicu seringkali merupakan pilihan terbaik. Jangan dengarkan fanatik anti pemicu dogmatis.

Pemicu yang mengirim email tidak selalu merupakan ide 'bodoh'. Apa yang bodoh adalah tidak mengantisipasi pemadaman email dalam desain dan menanganinya dengan anggun tanpa kehilangan data. Bagian 'bodoh' dari ini benar-benar buruk untuk penanganan kesalahan yang tidak ada oleh pengembang malas yang merasa mereka kebal terhadap kesalahan.

Saya juga akan menawarkan pengamatan bahwa pemicu dapat dibuat sederhana dengan menggunakan prosedur / fungsi tersimpan yang mungkin rumit dan dapat digunakan kembali oleh banyak pemicu atau prosedur tersimpan lainnya. Itu sebabnya ada paket dan perpustakaan.

Kefanatikan benar-benar melumpuhkan.