Saat mendesain database relasional yang besar, kita sering membuat keputusan untuk menyimpang dari bentuk normal, yaitu denormalisasi.
Alasan untuk ini bisa berbeda, seperti upaya untuk mempercepat akses ke data yang ditentukan, kendala platform/kerangka/alat pengembangan yang digunakan, dan kurangnya keterampilan pengembang/perancang database.
Sebenarnya, referensi ke batasan kerangka kerja, dll. sebenarnya adalah upaya untuk membenarkan kurangnya keterampilan.
Data yang didenormalisasi adalah kerentanan, yang dengannya database kami mudah dibawa ke status non-konsisten (non-integral).
Apa yang bisa kita lakukan dengan ini?
Contoh
Dalam database, ada tabel dengan beberapa operasi keuangan:penerimaan dan pengeluaran dana pada akun yang berbeda.
Kami selalu perlu mengetahui saldo akun.
Dalam data yang dinormalisasi, saldo dana selalu merupakan nilai yang dihitung. Kami akan menghitung total penerimaan tanpa pendebetan.
Namun, terlalu mahal untuk menghitung saldo setiap kali ada banyak operasi. Oleh karena itu, diputuskan untuk menyimpan saldo aktual dalam tabel terpisah. Bagaimana cara memperbarui data dalam tabel ini?
Solusinya adalah 'seperti biasa'
Hampir di semua sistem informasi tempat saya harus bekerja, tugas ini dilakukan oleh aplikasi eksternal, yang mengimplementasikan logika bisnis. Anda beruntung jika aplikasinya sederhana dan hanya ada satu titik perubahan data, dari formulir di antarmuka pengguna. Namun, bagaimana jika ada beberapa impor, API, aplikasi pihak ketiga, dll. yang dilakukan oleh orang dan tim yang berbeda? Bagaimana jika ada beberapa tabel dengan total, bukan satu? Bagaimana jika ada lebih dari satu tabel dengan operasi?
Semakin sulit untuk memantau apakah pengembang memperbarui banyak tabel saat memperbarui operasi. Data kehilangan integritas. Saldo akun tidak sesuai dengan operasi. Tentu saja, pengujian harus mengungkapkan situasi seperti itu. Namun, dunia kita tidak ideal.
Pemicu
Sebagai alternatif, pemicu digunakan untuk mengontrol integritas data yang didenormalisasi.
Saya mendengar bahwa pemicu sangat memperlambat database, jadi menggunakannya tidak masuk akal.
Argumen kedua adalah bahwa semua logika terletak pada aplikasi yang terpisah dan menjaga logika bisnis di tempat yang berbeda adalah tidak masuk akal.
Mari kita cari tahu.
Lag
Pemicu diaktifkan di dalam transaksi yang mengubah data dalam tabel. Transaksi tidak dapat diselesaikan sampai pemicu telah menjalankan langkah-langkah yang diperlukan. Oleh karena itu, kesimpulannya adalah pemicunya harus 'ringan'.
Contoh kueri 'berat' di pemicu adalah sebagai berikut:
update totals set total = select sum(operations.amount) from operations where operations.account = current_account where totals.account = current_account
Kueri merujuk ke tabel dengan operasi dan menjumlahkan jumlah total total operasi untuk akun .
Ketika database meningkat, kueri seperti itu akan menghabiskan lebih banyak waktu dan sumber daya. Namun, kami dapat menerima hasil yang sama menggunakan kueri ringan dari jenis berikut:
update totals set total = totals.total + current_amount where totals.account = current_account
Saat menambahkan baris baru, pemicu ini hanya akan menambah total akun tanpa menghitungnya. Total tidak tergantung pada jumlah data dalam tabel. Tidak masuk akal untuk menghitung total lagi, karena kita dapat yakin bahwa pemicu menyala setiap kali menambahkan operasi baru.
Menghapus atau memodifikasi baris diproses dengan cara yang sama. Pemicu jenis ini tidak akan memperlambat operasi, namun akan memastikan penggabungan dan integritas data.
Setiap kali saya mengalami "keterlambatan" saat menambahkan data ke tabel dengan pemicu, itu adalah contoh kueri yang "berat". Dalam kebanyakan kasus, dimungkinkan untuk menulis ulang dalam kueri "mudah".
Logika bisnis
Kita harus membedakan fungsi yang menyediakan integritas data dari logika bisnis. Dalam setiap kasus, saya mengajukan pertanyaan jika data dinormalisasi, apakah kita memerlukan fungsi seperti itu? Jika positif, fungsinya adalah logika bisnis. Jika negatif, fungsinya untuk memberikan integritas data. Anda dapat menggabungkan fungsi-fungsi ini menjadi pemicu.
Namun, ada pendapat bahwa mudah untuk mengimplementasikan semua logika bisnis melalui DBMS, seperti PostgreSQL atau Oracle.
Saya harap artikel ini akan membantu mengurangi jumlah bug di sistem informasi Anda.
Tentu saja, saya jauh dari berpikir bahwa semua yang tertulis di sini adalah kebenaran tertinggi. Dalam kehidupan nyata, tentu saja, semuanya jauh lebih rumit. Karena itu, Anda harus membuat keputusan dalam setiap kasus tertentu. Gunakan pemikiran teknik Anda!
P.S.
- Dalam artikel tersebut, saya menarik perhatian pada satu-satunya aspek penggunaan pemicu sebagai alat yang ampuh.
- Pendekatan yang dijelaskan dalam artikel memungkinkan menghindari indeks di Operasi tabel, yang pada gilirannya dapat mempercepat proses penambahan data ke tabel ini. Pada volume tinggi, pendekatan ini dengan mudah mengompensasi waktu yang dihabiskan untuk pemicu.
- Penting untuk memahami alat apa yang perlu kita gunakan. Dalam hal ini, Anda akan menghindari banyak masalah.
