Helo friends,
Mau tanya nich , Ane pengen buat aplikasi desktop yang menggunakan procedure & triger mysql.
apakah aplikasi yang ane buat ini bisa berjalan cepat jika dibandingkan dengan melakukan query langsung ( Onplay ) di source codenya.
Thaks Responsnya .
Rata-rata kalau pakai procedure & trigger bakal lebih cepat daripada kalau langsung query dari Java app.
Saran saya sich, pakai query langsung dulu..... sampai terbukti bahwa ada query2 yang sangat lambat sampai perlu mempertimbangkan menggunakan procedure/trigger. Itu pun coba gunakan cara lain tlebih dahulu, misalnya querynya diliat dulu, coba index-nya dioptimasi, struktur DBnya diubah agar sesuai utk query tsb, dll.
Why? Krn code Java lebih mudah diubah, dan bisa masuk SVN. Kcuali jika ada DBA khusus, saya berusaha menghindari mengubah skema database hanya sekedar ngedit2 SP dan trigger2nya. Apalagi kalo deployment DB tsb sudah ada beberapa (tidak hanya satu instansi). Sedangkan lumrah bagi aplikasi utk terus didevelop dan diupgrade.
Satu studi kasus adalah Facebook. Mereka punya scalability problem, tp approach mereka tdk hanya sekedar hajar DB atau hajar code.. penyelesaian utama mereka adalah menggunakan memcached.
Check this out:
http://www.slideshare.net/guoqing75/4069180-caching-performance-lessons-from-facebook
Saya lebih gak setuju lagi kalo ada banyak perintah apalagi logic di query tersebut.
Artinya DB logic menjadi kompleks, dan ini sumber dari runtime errors.
Karena mempersulit:
Maintenance software, meski gak gampang, masih lebih ringan daripada maintenance DB.
Satu kelebihan Java code adalah mudah dilakukan unit testing, termasuk untuk mengetes logic dalam sebuah transaction. Theoretically, asal testnya bagus, apabila unit tests pass berarti program berjalan baik. Prakteknya tetep ada issue, sih, but that's better daripada nggak ada support unit testing sama sekali (untuk MySQL procedures, kalo Oracle dll sepertinya dukungan lebih baik).
Saya bukan anti-procedures, tp memang bias ke no-procedures. Menurut saya, stored procedures adalah pilihan terakhir dan hanya digunakan untuk masalah performance yg akut.. yg tdk bisa dipecahkan dengan alternatif solusi yg lain.
Saran saya sich, pakai query langsung dulu..... sampai terbukti bahwa ada query2 yang sangat lambat sampai perlu mempertimbangkan menggunakan procedure/trigger. Itu pun coba gunakan cara lain tlebih dahulu, misalnya querynya diliat dulu, coba index-nya dioptimasi, struktur DBnya diubah agar sesuai utk query tsb, dll.
Why? Krn code Java lebih mudah diubah, dan bisa masuk SVN. Kcuali jika ada DBA khusus, saya berusaha menghindari mengubah skema database hanya sekedar ngedit2 SP dan trigger2nya. Apalagi kalo deployment DB tsb sudah ada beberapa (tidak hanya satu instansi). Sedangkan lumrah bagi aplikasi utk terus didevelop dan diupgrade.
Satu studi kasus adalah Facebook. Mereka punya scalability problem, tp approach mereka tdk hanya sekedar hajar DB atau hajar code.. penyelesaian utama mereka adalah menggunakan memcached.
Check this out:
http://www.slideshare.net/guoqing75/4069180-caching-performance-lessons-from-facebook
Saya lebih gak setuju lagi kalo ada banyak perintah apalagi logic di query tersebut.
Artinya DB logic menjadi kompleks, dan ini sumber dari runtime errors.
Karena mempersulit:
- unit testing
- debugging kalo ada masalah
- maintenance DB jadi lebih berat
- nggak bisa lihat history (via SCM)
Maintenance software, meski gak gampang, masih lebih ringan daripada maintenance DB.
Satu kelebihan Java code adalah mudah dilakukan unit testing, termasuk untuk mengetes logic dalam sebuah transaction. Theoretically, asal testnya bagus, apabila unit tests pass berarti program berjalan baik. Prakteknya tetep ada issue, sih, but that's better daripada nggak ada support unit testing sama sekali (untuk MySQL procedures, kalo Oracle dll sepertinya dukungan lebih baik).
Saya bukan anti-procedures, tp memang bias ke no-procedures. Menurut saya, stored procedures adalah pilihan terakhir dan hanya digunakan untuk masalah performance yg akut.. yg tdk bisa dipecahkan dengan alternatif solusi yg lain.
No comments:
Post a Comment