Alasan Tidak Menggunakan Stored Procedures

Maintenance DB

Utk maintenance DB... Memang betul, itulah gunanya DBA...

Sebaliknya, dengan membatasi penggunaan fitur2 DBMS, peran DBA bisa diminimalkan bahkan mungkin dihilangkan.

Performa

SP menawarkan performa lebih baik.. Memang benar. Jika pilihannya adalah tanpa SP = lambat dan pakai SP = cepat, saya SP adalah solusi yang baik.

Namun jika pilihannya adalah tanpa SP = cepat dan pakai SP = sedikit lebih cepat, maka bila tetap memakai SP saya menyebutnya premature optimization. Use the rule "Performance is not a problem before performance is a problem" sama Keep It Simple.. No SP is simpler. Rule saya sendiri: gunakan SP hanya jika terpaksa, bukan menggunakan SP sebagai business logic API (setiap fungsi di-wrap dalam SP).

Stored Procedures as Best Practice?

Sebenarnya bisa dimengerti apabila SP dimasukkan sebagai best practice untuk sebuah DBMS (I think it's more marketing than technical).

Tentang prepared statements, yang tidak berhubungan dengan SP, meski fungsinya sedikit mirip. Prepared statement menyiapkan sebuah query untuk dieksekusi berulang2 dengan parameter yang berbeda-beda.

Perbedaannya sangat mendasar: source code SP disimpan dalam database, sedangkan prepared statement code-nya tetap berasal dari aplikasi. App tetap memegang kendali penuh atas code, dan karena it's app code, bisa masuk ke SCM.

Kalau prepared statement... ini memang benar-benar best practices, dan bisa (wajib) diterapkan di app Java terlepas apakah menggunakan SP maupun tidak. Saya jadi curiga, apa semua parameterized query di Java (dari level JDBC) sudah di-prepared statement?

Correctness vs. Unit Testing

Logic yang benar "saat ini" tidak berarti bahwa logic tersebut akan tetap benar saat ada perubahan berikutnya. Ini gunanya unit testing, yang cukup mudah diaplikasikan di Java. Dan ada lagi functional testing dan integration testing.

Develop app Java akan lebih mudah dan tidak terlalu mengkhawatirkan dengan adanya test suites yang baik. Kalau ada perubahan yang memunculkan kesalahan, seharusnya tests jadi FAIL.

Hal ini jadi lebih sulit kalau SP ada di dalam database, karena unit testing lebih sulit. Bukan berarti tidak mungkin... tapi kecenderungannya developer mau menulis test code apabila semakin mudah melakukan unit test. Utk membuat unit test dengan SP, maka harus dilakukan testing dengan real DBMS.. ada banyak issue di sini, misalnya performance dan lifecycle (startup/teardown) serta mungkin workaround. Bila tanpa SP dan implementasi berbasis POJO, unit testing dapat menggunakan mocks.

Sejujurnya, saya sendiri suka malas bikin tests, padahal (relatif) gampang banget, sudah ada Maven, JUnit, Spring test integration, dan didukung IDE. apalagi kalo ribet yah.. gitu sih..

Conclusion

Kesimpulan saya, SP vs no-SP adalah tradeoff, tdk ada salah satu pendekatan yang paling superior. Ada compromise yang harus dipilih. Secara pribadi saya memang bias ke no-SP, dalam artian SP hanya digunakan apabila terpaksa, "default" mode-nya adalah no-SP.

Mirip dengan rasionalisasi ttg memcached. memcached tidak digunakan secara "hantam kromo", check this out: http://www.slideshare.net/err/kickin-ass-with-cachefu

Kutipan:

1. YAGNI ya ain't gonna need it none of the big guys built memcache into their infrastructure (just ask twitter) build it in later focus on your app first in small apps it is slower than sql hardware is the real special sauce memcached wont help if you cant keep up with the IO requests you probably don't need memcache...
2. UYRDNI er-den-ee...
3. UYRDNI (unless you really do need it) this would be: - millions of hits - millions of rows - millions of both if you're getting these, you can use memcached to help with the heavy lifting...