Menggunakan pemicu atau transaksi MySQL?

Saya ingin menanyakan pendapat Anda dalam menggunakan pemicu MySQL atau transaksi di situs web.

Sebenarnya saya punya paymenttabel sejarah dengan - UserId | OperationId | Comment | Credits | Sign (debit or credit). Jadi setiap operasi pembayaran dimasukkan dalam tabel ini.

Namun, itu akan memakan waktu menghitung setiap kali jumlah total kredit pengguna setiap kali dia melakukan tindakan. Jadi saya pikir mungkin ide yang bagus untuk menyimpan jumlah total kredit untuk setiap pengguna dalam profiletabel pengguna .

Inilah masalahnya. Bagaimana saya bisa yakin bahwa jumlah total kredit dari profiletabel akan tetap disinkronkan dengan operasi dari paymenttabel histori?

Saya pikir menggunakan 2 metode:

• MySQL memicu atau
• transaksi dikodekan dalam kode sumber

Mana yang lebih bisa diandalkan? Bagaimana jika saya memiliki basis data besar (lebih dari 100.000 pengguna)?

Apakah Anda punya saran untuk melakukan ini?

Mesin BD BD adalah InnoDB.

Tanpa ragu, saya akan mengesampingkan pemicu dan tetap dengan transaksi.

Pemicu pada dasarnya adalah prosedur tersimpan. Tindakan mereka sebenarnya sulit untuk dibatalkan . Bahkan jika semua tabel yang mendasari adalah InnoDB, Anda akan mengalami volume proporsional kunci baris bersama dan intermittency mengganggu dari kunci baris eksklusif. Ini akan menjadi kasus jika pemicu memanipulasi tabel dengan INSERT dan UPDATE sedang mandek untuk melakukan tugas berat MVCC di dalam setiap panggilan ke pemicu .

Gabungkan ini dengan fakta bahwa protokol validasi data yang tepat tidak diimplementasikan dalam Bahasa Prosedur yang Disimpan MySQL . Business Intelligence OK untuk terkandung dalam database asalkan Bahasa Prosedur Tersimpan dapat menangani lingkungan transaksional . Sebagai DBA MySQL, saya harus jujur ​​mengatakan bahwa tidak demikian halnya dengan MySQL. Oracle (PL / SQL), PostgreSQL (PL / pgSQL), dan SQL Server (T-SQL) lebih unggul dari MySQL.

Mengenai transaksi, MySQL memiliki InnoDB sebagai mesin penyimpanan utama ACID-compliant (mesin penyimpanan Deafult di MySQL 5.5). Ini memiliki pemulihan crash yang sangat baik dan mematuhi protokol kepatuhan ACID.

Saya akan memilih transaciton daripada pemicu setiap saat.

Saya setuju dengan penilaian Rolando. Logika bisnis Anda harus ada di aplikasi Anda dan harus membuat perubahan pada basis data secara transaksi.

Penskalaan ke 100.000 pengguna, tentu saja, tergantung pada aplikasi Anda dan lalu lintas basis data yang dihasilkannya. Dengan MySQL di bawah beban tulis transaksional yang berat, Anda mungkin akan segera dihadapkan dengan beban sharding dan / atau mereplikasi dataset Anda untuk mempertahankan respons aplikasi yang dapat diterima.

Namun, ada alternatif untuk sharding MySQL. Salah satunya adalah Clustrix (atasan saya) yang merupakan sistem database SQL instance-tunggal paralel dengan kinerja tinggi yang dapat diskalakan. Ini adalah sistem basis data berkerumun yang menghadirkan dirinya sebagai server MySQL tunggal. Melakukan penskalaan basis data yang diuraikan dalam utas ini secara mulus ke 100.000 pengguna pada satu contoh Clustrix tidak memerlukan pembatalan dan tidak ada logika aplikasi tambahan.

Jawaban bagus dari Rolando.

Selain itu - Pemicu tidak boleh digunakan untuk logika, karena beberapa pemicu yang saling terkait nanti, semuanya akan membingungkan dengan cepat. Seperangkat instruksi yang bagus dalam prosedur tersimpan atau prosedur sisi klien dapat melintasi logika bisnis lebih jelas daripada sekelompok logika tersembunyi dalam database. Ada juga batasan pada pemicu sehubungan dengan tabel mereka dipicu dari - jadi Anda mungkin menemukan diri Anda membelah logika Anda di dua tempat yang berbeda ..

Selain itu - Anda mungkin menemukan cara untuk mengoptimalkan pada titik apa perhitungan ini terjadi di server logika bisnis Anda, sedangkan pemicu akan dipicu setiap saat. Anda akan menemukan diri Anda mematikan pelatuk, memperbarui meja, dan kemudian kembali memungkinkan memicu - yang juga berarti Anda harus menempatkan logika memicu dalam yang kode.

Selain itu - Anda tidak harus memiliki semua logika di bagian logika bisnis dari kode - Anda mungkin ingin menegakkan integritas tabel dengan menggunakan prosedur tersimpan. Ini dapat memulai transaksi, melakukan banyak pembaruan, dan membuat semuanya kembali dengan baik jika ada yang gagal. Dengan cara itu seseorang yang melihat database dapat melihat logika untuk memasukkan pesanan, misalnya. Ini kurang penting di dunia saat ini karena layanan web dapat menjadi antarmuka akses tunggal ke db; tetapi dalam kasus di mana banyak executable memiliki akses ke DB ini bisa sangat besar.

Selain itu - Anda akan tetap melakukan transaksi - Anda tidak akan menjalankan pemicu Anda tanpa ... benar? Jadi, baik untuk mengetahui cara memulai transaksi; melakukan beberapa hal; dan kemudian mengakhiri transaksi. Jika Anda melihat pola ini dalam kode Anda, satu lagi kode yang menggunakannya akan menjadi ringan pada beban kognitif. Pemicu, jika Anda ingat bahwa itu ada, akan memaksa Anda untuk berpikir secara berbeda untuk transaksi-transaksi yang dipengaruhi oleh pemicu, terutama jika tabel lain ditarik yang juga mungkin memiliki pemicu.

Pada dasarnya, antara pekerjaan cron yang dijadwalkan secara rutin (atau pekerjaan agen basis data) dan prosedur tersimpan yang baik, Anda dapat mencapai 99% dari apa yang Anda inginkan. 1%; memikirkan kembali proyek.