Tentang Stored Procedure di MySQL (Tugas Sistem Basis Data II)

Gambar dari : Fahrial.web.id

Pada postingan kali ini saya akan membagikan kepada teman-teman mengenai “Stored Procedure”, apa itu stored procedure ?? apa kegunaan stored procedure ?? dan apa saja keuntungan menggunakan stored procedure dalam suatu sistem (database) ?? serta apa saja kelemahan Stored Procedure ??.
Untuk lebih jelasnya silahkan dibaca postingan dibawah ini =

1. Apa itu Stored Procedure ??
Stored Procedure adalah sekumpulan perintah SQL yang disusun dalam sebuah procedure yang memiliki nama dan fungsi tertentu.
Jadi, sebuah Stored Prosedure adalah prosedur (ditulis dalam SQL dan pernyataan kontrol lainnya) disimpan dalam database yang dapat dipanggil oleh mesin database dan terhubung dengan bahasa pemrograman. Stored Procedure juga tersedia di server database umum lainnya (Misalnya Postgre SQL).

2. Mengapa direkomendasikan untuk menggunakan ??
Sebagian besar dari kita sudah familiar dengan setup yang normal untuk membangun aplikasi database: membuat database, membuat tabel, mengatur indeks, CRUD data, melakukan query dari sisi klien dan melakukan proses lebih lanjut jika diperlukan.
Alur kerja tersebut bekerja dengan baik dalam banyak kasus tapi ada satu aspek penting dari pemrograman database hilang: Stored Procedure.

3. Apa keuntungan menggunakan Stored Procedure ??
Setidaknya ada empat keuntungan yang saya ketahui dengan menggunakan SP dalam aplikasi database.

a.   Pertama, mengurangi lalu lintas jaringan dan overhead. Dalam database PHP aplikasi web yang khas, ada empat lapisan:
·        Layer klien, yang mana normalnya adalah browser web. Ia menerima interaksi user dan menampilkan data di user interface.
·        Layer web server, yang menangani dan memilah permintaan user dan mengirim balik response yang diberikan ke layer klien.
·        Layer PHP, yang menangani semua interpretasi PHP, melakukan logika aplikasi, dan menghasilkan response dari PHP.
·        Layer Database, yang menangani semua query database, termasuk tidak terbatas pada sebuah query SELECT, pernyataan INSERT, dan seterusnya.
Dalam lingkungan yang khas, lapisan ini akan kemungkinan besar tidak berada pada satu mesin tunggal, bahkan mungkin tidak dalam satu jaringan, untuk aplikasi yang lebih besar.
Meskipun kecepatan jaringan telah sangat meningkat dalam beberapa tahun terakhir, masih paling lambat dan paling tidak dapat diandalkan dibandingkan dengan cara lain untuk mentransfer data (CPU cache, memori, hard disk, dll). Jadi, untuk menghemat bandwidth dan meningkatkan ketahanan, kadang-kadang ide yang baik untuk memiliki lebih banyak pengolahan dan logika yang dilakukan pada sisi server (khususnya, server MySQL) dan memiliki sedikit data yang ditransfer melalui jaringan.

b.   Kedua, meningkatkan kinerja. SP disimpan dan dijalankan langsung di server MySQL. Hal ini dapat menjadi pra-kompilasi dan dianalisa oleh database server. Ini sangat berbeda dari mengeluarkan permintaan yang sama dari sisi client, di mana permintaan akan diurai oleh database driver, dianalisis dan dioptimalkan (jika mungkin) pada setiap kali pernyataan query disebut. Hal ini entah bagaimana mirip eksekusi bahasa dengan interpreter  (pada akhir client) dan eksekusi bahasa terkompilasi (pada akhir database server). Dan kita tahu program yang dikompilasi akan berjalan lebih cepat.

c.   Ketiga, Tulis sekali dan Jalankan dan mana saja. SQL adalah standar dan murni 100% platform independen. Hanya mengandalkan pada server database. Pertimbangkan berapa banyak berbeda bahasa / libs ada yang bisa kita gunakan untuk menangani database. Hal ini meningkatkan efisiensi dengan menempatkan penerimaan dan pengolahan data pada akhir server daripada menulis logika pengolahan yang sama dalam sintaks yang berbeda yang disediakan oleh semua bahasa / libs, jika logika pengolahan datanya sangat umum digunakan.

d.   Terakhir, SP merupakan aspek fundamental dari keamanan database.

Mari kita mempertimbangkan setup database sederhana. Dalam sistem informasi sumber daya manusia (HRIS), adalah wajar untuk mengasumsikan bahwa ada sebuah tabel yang memegang informasi gaji masing-masing karyawan. Seorang karyawan HR harus memiliki hak untuk mengambil beberapa angka dari tabel ini: Jumlah gaji, gaji rata-rata, dll tapi karyawan ini seharusnya tidak melihat gaji rinci dari setiap karyawan karena informasi ini akan terlalu sensitif dan seharusnya hanya tersedia untuk beberapa .

Kita tahu MySQL memiliki kontrol hak istimewa yang komprehensif. Dalam hal ini, jelas bahwa kita bahkan tidak bisa memberikan hak istimewa SELECT pada karyawan HR ini (yang, jika kita lakukan, berarti dia / dia bisa melihat gaji rinci semua orang). Tapi jika dia / dia tidak dapat mengakses tabel gaji, bagaimana karyawan ini bisa mendapatkan informasi agregasi berkaitan dengan gaji? Bagaimana kita bisa memungkinkan karyawan untuk mengambil informasi yang tanpa mengorbankan kebijakan HR?

Jawabannya adalah menggunakan Stored Prosedur yang mengembalikan informasi yang diperlukan dan memberikan karyawan yang berhak dengan hak akses Execute. (Untuk daftar rinci dan penjelasan tentang hak akses pada MySQL, silakan berkonsultasi di dokumentasi resmi. Link di sini adalah untuk MySQL 5.6. Silakan ganti 5.6 dengan versi yang Anda gunakan.)

SP sekarang adalah jembatan, menjembatani user (karyawan HR) dan tabel (gaji), yang mana pengguna tidak memiliki akses langsung.

Itu saja! Dengan SP, kita bisa mendapatkan pengguna untuk menyelesaikan tugas tanpa mengorbankan keamanan database (dan kebijakan SDM)!

4. Kerugian menggunakan Stored Procedures
Setelah menguraikan semua keuntungan dari menggunakan SP, kita harus jelas tentang beberapa kelemahan dan melihat apakah ada cara untuk memperbaikinya.

     a.   Tidak ada kontrol versi di SP itu sendiri . Ketika SP dimodifikasi , hal itu diubah , tidak ada jejak sejarah dapat disimpan di sisi server . Ini mungkin membuat beberapa frustrasi ketika pengguna ingin merollback perubahan. Saran saya adalah untuk menulis SP di sisi klien Anda dan meletakkannya di bawah kontrol versi . Ketika SP sudah siap , mudah untuk menyalin kode ke , katakanlah MySQL Workbench dan menciptakan itu pada sisi server . Dengan demikian , kita dapat memiliki beberapa tingkat kontrol versi .

     b.   Tidak ada cara mudah untuk melakukan “sinkronisasi ” perubahan yang diterapkan dan memaksa semua orang untuk menggunakan versi terbaru , khususnya, ketika masing-masing anggota tim memiliki database lokalnya sendiri untuk tujuan pengembangan dan pengujian . Versi kontrol dapat menjadi solusi namun masih membutuhkan intervensi manual dengan memperbarui salinan lokal dari SP di server db lokal . Cara lain adalah dengan menggunakan “mocking” . Anggota tim dapat dibagi sehingga setidaknya satu orang akan fokus pada pemeliharaan SP dan pelaksanaan panggilan kepada SP dalam kode . Semua orang lain yang membutuhkan hasil dari SP dapat mengembangkan dan menguji bagian mereka menggunakan objek mocking, yaitu , selalu dengan asumsi  panggilan “palsu” pada SP akan mengembalikan hasil yang diinginkan . Dalam tahap selanjutnya, penggabungan dapat dilakukan dengan membuang kode mocking.

     c.   Sulit untuk membackup/mengekspornya. SP adalah pada sisi server . Pengembang reguler hanya akan memiliki hak dasar ( SELECT , Execute , dll ) dan tidak ada hak admin untuk membackup dan mengekspor . Di satu sisi , saya tidak akan menyebutnya kelemahan melainkan aspek fundamental dari keamanan db. Tidak ada cara, dan tidak dianjurkan di area ini . Disarankan bahwa, dalam sebuah tim , DB admin khusus akan ditunjuk untuk melakukan pekerjaan tersebut . Sebuah backup db biasa juga dapat melayani tujuan backup/ekspor ( dan impor ) .

    Sekian postingan saya kali ini, semoga bermanfaat buat kalian semua.