Stored Procedure Adalah: Fungsi, Jenis, dan Contohnya

Setiap kali aplikasi membutuhkan data, ia mengirim perintah SQL ke database lalu menunggu jawabannya kembali. Untuk satu perintah SELECT sederhana, perjalanan bolak-balik itu nyaris tidak terasa. Persoalannya muncul saat satu tugas membutuhkan tujuh perintah berurutan yang saling bergantung, misalnya mengecek stok, menguranginya, mencatat transaksi, memperbarui saldo, lalu menulis catatan aktivitas. Ketujuh perintah itu berangkat satu per satu, dan aplikasi menunggu di setiap perjalanan.

Stored procedure adalah jawaban lama untuk persoalan tersebut, dan namanya sudah menjelaskan dirinya sendiri. Stored artinya tersimpan, bentuk lampau dari store yang berarti menyimpan. Jadi istilah ini secara harfiah menunjuk pada prosedur yang menetap di dalam database, bukan prosedur yang dikirim ulang setiap kali dibutuhkan. Anda mungkin sering menjumpai penulisan "store procedure" tanpa huruf d di akhir kata pertama; bentuk bakunya adalah stored procedure.

Artikel ini membahas pengertiannya, cara database menjalankannya, jenis-jenisnya, dan contoh sintaks di tiga sistem database populer. Dibahas pula cara melihat serta menghapus prosedur yang sudah ada, berikut pertimbangan sebelum Anda memindahkan logika aplikasi ke dalam database.

Apa Itu Stored Procedure?

Stored procedure adalah sekumpulan perintah SQL yang diberi nama, disimpan permanen di dalam database, dan dijalankan dengan satu panggilan. Prosedur ini dapat menerima parameter masukan, mengerjakan serangkaian operasi, lalu mengembalikan hasil atau nilai keluaran kepada pemanggilnya.

Kalau Anda terbiasa bekerja lewat terminal, konsepnya mirip dengan menyimpan skrip di server ketimbang mengetik ulang seluruh perintahnya satu per satu setiap kali dibutuhkan. Bedanya, skrip ini tinggal di dalam database dan dieksekusi oleh mesin database itu sendiri, bukan oleh sistem operasi.

Kemampuan ini bukan fitur tambahan buatan satu vendor. Ia berasal dari SQL/PSM (Persistent Stored Modules), standar yang terbit sebagai ISO/IEC 9075-4:1996 pada Desember 1996 sebagai perluasan SQL-92. Standar inilah yang mendefinisikan variabel lokal, percabangan, perulangan, dan penanganan kesalahan di dalam SQL.

Ada satu detail penting dari standar tersebut: fitur di Part 4 bersifat opsional. Setiap pembuat database bebas menerapkannya sebagian, seluruhnya, atau tidak sama sekali. Dari sinilah lahir perbedaan sintaks yang akan Anda temui di bagian contoh nanti.

Cara Kerja Stored Procedure di Dalam Database

Ketika aplikasi memanggil sebuah prosedur, yang melintasi jaringan hanyalah nama prosedur beserta parameternya. Database kemudian mencari definisi prosedur tersebut, menyiapkan execution plan (rencana eksekusi, yaitu peta langkah yang dipilih database untuk mengambil data), lalu menjalankan seluruh isinya di sisi server.

Alur stored procedure: aplikasi mengirim satu perintah CALL, database menjalankan semua isinya, satu jawaban kembali.

Perbedaannya dengan query biasa terletak pada jumlah perjalanan. Tujuh perintah terpisah berarti tujuh kali menunggu jaringan; satu prosedur berisi tujuh perintah berarti satu kali menunggu. Selisih ini terasa paling nyata pada aplikasi yang databasenya berada di server berbeda.

Satu catatan teknis yang jarang disadari pemula: server database memakai snapshot (potret) definisi prosedur saat sebuah perintah mulai dijalankan. Kalau ada sesi lain mengubah prosedur di tengah eksekusi, perubahan itu tidak akan terlihat oleh perintah yang sedang berjalan.

Jenis-Jenis Stored Procedure

Dokumentasi SQL Server membagi stored procedure menjadi lima jenis. Pembagian ini paling rinci di antara sistem database yang ada, dan konsepnya membantu memahami produk lain juga.

1. User-defined: prosedur yang Anda tulis sendiri, baik dalam Transact-SQL maupun sebagai rujukan ke metode .NET. Inilah jenis yang dimaksud orang saat menyebut stored procedure tanpa keterangan tambahan.
2. Temporary: prosedur sementara yang disimpan di database tempdb. Nama berawalan satu tanda pagar (#nama) menjadikannya lokal, hanya terlihat oleh koneksi yang membuatnya dan terhapus saat koneksi ditutup. Dua tanda pagar (##nama) menjadikannya global, terlihat oleh semua pengguna dan terhapus setelah sesi terakhir yang memakainya berakhir.
3. System: prosedur bawaan mesin database, berawalan sp_. Fisiknya tersimpan di database internal bernama Resource yang tersembunyi, tetapi secara logis muncul di skema sys pada setiap database.
4. Extended user-defined: rutin eksternal berbentuk DLL yang ditulis dengan bahasa seperti C, berawalan xp_. Microsoft menyatakan jenis ini akan dihapus pada versi mendatang dan meminta pengembang tidak memakainya untuk pekerjaan baru.
5. CLR: metode .NET yang didaftarkan sebagai prosedur. Inilah pengganti yang direkomendasikan untuk kebutuhan yang dulu dilayani extended stored procedure.

Karena prosedur sistem memakai awalan sp_, jangan menamai prosedur buatan Anda sendiri dengan awalan yang sama. Selain berisiko bentrok saat versi database diperbarui, penamaan itu memaksa mesin database mencari lebih dulu ke database sistem sebelum menemukan prosedur Anda.

Perbedaan Stored Procedure dengan Function, View, dan Trigger

Empat objek ini sama-sama menyimpan logika di dalam database, tetapi perannya berbeda. Tabel berikut merangkum pembedanya.

Perbedaan antara procedure dan function adalah yang paling sering ditanyakan, dan MySQL memberi contoh batas yang tegas. Di MySQL, parameter sebuah function selalu bersifat masukan; penanda IN, OUT, dan INOUT hanya berlaku untuk procedure. Function juga dilarang memakai dynamic SQL, yaitu perintah yang disusun sebagai teks lalu dijalankan. Larangan lainnya, function tidak boleh memuat perintah yang mengembalikan result set tanpa INTO, dan tidak boleh mengubah tabel yang sedang dibaca oleh perintah pemanggilnya.

Singkatnya, function dirancang untuk menghitung dan mengembalikan nilai, sementara procedure dirancang untuk mengerjakan sesuatu.

Sintaks dan Contoh Stored Procedure

Bagian ini memakai satu skenario yang sama di tiga sistem database, yaitu mencatat pembayaran sebuah tagihan lalu memperbarui sisa tagihannya. Skenario yang sama memudahkan Anda membandingkan perbedaan sintaksnya.

Contoh Stored Procedure MySQL

MySQL baru mendukung stored procedure sejak versi 5.0, yang mencapai status stabil lewat rilis 5.0.15 pada 19 Oktober 2005. Karena badan prosedur berisi banyak perintah yang dipisah titik koma, Anda perlu mengganti penanda akhir perintah lebih dulu dengan DELIMITER agar klien tidak salah membaca batas perintah.

DELIMITER $$

CREATE PROCEDURE catat_pembayaran(
    IN p_invoice_id INT,
    IN p_jumlah DECIMAL(12,2),
    OUT p_sisa DECIMAL(12,2)
)
BEGIN
    INSERT INTO pembayaran (invoice_id, jumlah, dibayar_pada)
    VALUES (p_invoice_id, p_jumlah, NOW());

    UPDATE invoice
    SET sisa_tagihan = sisa_tagihan - p_jumlah
    WHERE id = p_invoice_id;

    SELECT sisa_tagihan INTO p_sisa
    FROM invoice
    WHERE id = p_invoice_id;
END$$

DELIMITER ;

Prosedur di atas memakai dua parameter masukan dan satu parameter keluaran. Mode IN adalah bawaan, sehingga penulisannya boleh dihilangkan, tetapi menuliskannya secara eksplisit membuat maksud kode lebih jelas. Parameter OUT selalu bernilai NULL di awal eksekusi dan baru terisi oleh isi prosedur.

Untuk menjalankannya, kirimkan CALL beserta variabel penampung nilai keluaran.

CALL catat_pembayaran(1042, 250000, @sisa);
SELECT @sisa;

Perhatikan bahwa tanda kurung tetap wajib ditulis meski prosedur Anda tidak memiliki parameter sama sekali.

Contoh Stored Procedure SQL Server

SQL Server memakai Transact-SQL, dengan parameter berawalan tanda @ dan pemanggilan lewat EXEC. Baris SET NOCOUNT ON mencegah pesan jumlah baris terpengaruh ikut terkirim dan mengganggu result set yang sesungguhnya.

CREATE PROCEDURE dbo.CatatPembayaran
    @InvoiceId INT,
    @Jumlah DECIMAL(12,2)
AS
BEGIN
    SET NOCOUNT ON;

    INSERT INTO dbo.Pembayaran (InvoiceId, Jumlah, DibayarPada)
    VALUES (@InvoiceId, @Jumlah, SYSDATETIME());

    UPDATE dbo.Invoice
    SET SisaTagihan = SisaTagihan - @Jumlah
    WHERE Id = @InvoiceId;

    SELECT SisaTagihan FROM dbo.Invoice WHERE Id = @InvoiceId;
END;
GO

Pemanggilannya menyebut nama parameter secara eksplisit, sehingga urutannya tidak perlu dihafal.

EXEC dbo.CatatPembayaran @InvoiceId = 1042, @Jumlah = 250000;

Menuliskan nama skema di depan nama prosedur, seperti dbo. pada contoh di atas, bukan sekadar kerapian. Mesin database mencocokkan rencana eksekusi yang tersimpan hanya jika seluruh rujukan objek ditulis lengkap.

Contoh Stored Procedure PostgreSQL

PostgreSQL termasuk yang paling belakangan menyediakan prosedur. Sebelum versi 11 yang rilis pada 18 Oktober 2018, satu-satunya pilihan adalah CREATE FUNCTION. Catatan rilisnya menyebut prosedur baru ini dapat memulai dan menutup transaksinya sendiri, kemampuan yang tidak dimiliki function.

CREATE PROCEDURE catat_pembayaran(p_invoice_id INT, p_jumlah NUMERIC)
LANGUAGE plpgsql
AS $$
BEGIN
    INSERT INTO pembayaran (invoice_id, jumlah, dibayar_pada)
    VALUES (p_invoice_id, p_jumlah, now());

    UPDATE invoice
    SET sisa_tagihan = sisa_tagihan - p_jumlah
    WHERE id = p_invoice_id;

    COMMIT;
END;
$$;

Perintah COMMIT di dalam badan prosedur itulah kemampuan yang dimaksud catatan rilis PostgreSQL 11. Namun ada syaratnya: prosedur yang dideklarasikan dengan SECURITY DEFINER atau klausa SET tidak diizinkan menjalankan perintah kontrol transaksi.

Pemanggilannya sama seperti MySQL, memakai CALL dan bukan SELECT.

CALL catat_pembayaran(1042, 250000);

Jadi, jawaban untuk pertanyaan tentang perintah menjalankan stored procedure yang telah dibuat adalah CALL pada MySQL, PostgreSQL, dan Oracle, serta EXEC atau EXECUTE pada SQL Server.

Melihat, Mencari, dan Menghapus Stored Procedure

Setelah beberapa bulan berjalan, sebuah database bisa menampung puluhan prosedur. Berbeda dengan kode aplikasi yang bisa Anda telusuri dengan pencarian teks biasa di folder proyek, kode prosedur tersimpan di dalam database. Menemukannya kembali membutuhkan query tersendiri.

Di MySQL, katalog INFORMATION_SCHEMA.ROUTINES menyimpan definisi setiap rutin. Tiga perintah berikut menutupi hampir semua kebutuhan sehari-hari.

-- Daftar prosedur di sebuah database
SHOW PROCEDURE STATUS WHERE Db = 'nama_database';

-- Tampilkan kode lengkap satu prosedur
SHOW CREATE PROCEDURE catat_pembayaran;

-- Cari prosedur mana saja yang menyentuh tabel invoice
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, LAST_ALTERED
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE = 'PROCEDURE'
  AND ROUTINE_DEFINITION LIKE '%invoice%';

Kalau kolom ROUTINE_DEFINITION mengembalikan NULL padahal prosedurnya jelas ada, penyebabnya hampir selalu privilese. MySQL hanya menampilkan isi definisi kepada pemilik DEFINER, pemegang privilese SHOW_ROUTINE, atau pemegang SELECT di tingkat global. Akun yang hanya berbekal CREATE ROUTINE, ALTER ROUTINE, atau EXECUTE akan melihat NULL.

Di SQL Server, definisinya berada di katalog sys.sql_modules, sementara daftar prosedurnya di sys.procedures. Kolom modify_date sekaligus menjawab pertanyaan kapan sebuah prosedur terakhir diubah.

-- Daftar prosedur beserta tanggal perubahan terakhir
SELECT SCHEMA_NAME(schema_id) AS skema, name, modify_date
FROM sys.procedures
ORDER BY modify_date DESC;

-- Cari prosedur mana saja yang menyentuh tabel Invoice
SELECT OBJECT_SCHEMA_NAME(m.object_id) AS skema,
       OBJECT_NAME(m.object_id) AS nama_prosedur
FROM sys.sql_modules AS m
INNER JOIN sys.procedures AS p ON m.object_id = p.object_id
WHERE m.definition LIKE '%Invoice%';

Kolom definition bernilai NULL untuk prosedur yang dienkripsi, jadi pencarian teks tidak akan menemukannya.

Menghapus prosedur memakai DROP PROCEDURE, dan penambahan IF EXISTS mencegah galat bila prosedurnya memang sudah tidak ada.

DROP PROCEDURE IF EXISTS catat_pembayaran;      -- MySQL dan PostgreSQL
DROP PROCEDURE IF EXISTS dbo.CatatPembayaran;   -- SQL Server 2016 ke atas

Pada PostgreSQL, daftar parameter boleh dihilangkan selama hanya ada satu prosedur dengan nama tersebut. Bila namanya dipakai beberapa prosedur dengan parameter berbeda, tipe parameternya wajib disebutkan.

Dua kebiasaan penamaan berikut menghemat banyak waktu di kemudian hari. Pertama, hindari awalan sp_ dan pakai usp_ sebagai gantinya, seperti yang dicontohkan Microsoft sendiri lewat nama uspGetCustomerCompany di dokumentasinya. Kedua, jangan mengganti nama prosedur dengan sp_rename di SQL Server. Perintah itu tidak ikut memperbarui nama di dalam kolom definition, sehingga kode yang tersimpan menjadi tidak sesuai dengan nama objeknya. Microsoft menyarankan menghapus lalu membuat ulang prosedur dengan nama barunya.

Keuntungan Memakai Stored Procedure

1. Lalu lintas jaringan berkurang: seluruh perintah dieksekusi sebagai satu kesatuan, sehingga hanya panggilannya yang melintasi jaringan. Tanpa pembungkus ini, setiap baris kode harus menyeberang satu per satu.
2. Satu logika dipakai banyak aplikasi: bila aplikasi web, layanan latar belakang, dan skrip laporan membutuhkan perhitungan yang sama, logikanya cukup ditulis sekali di database. Ketiganya memanggil prosedur yang sama tanpa peduli bahasa pemrogramannya.
3. Izin akses menjadi lebih rapi: pengguna dapat diberi hak EXECUTE pada sebuah prosedur tanpa diberi hak apa pun pada tabel di baliknya. Dokumentasi Microsoft memberi contoh yang tepat, yaitu perintah TRUNCATE TABLE yang tidak punya izin khusus dan menuntut hak ALTER pada tabel. Membungkusnya dalam prosedur dengan klausa EXECUTE AS memberi pengguna kemampuan mengosongkan tabel tanpa memberinya hak mengubah struktur tabel.
4. Perubahan skema tidak menyeret sisi aplikasi: selama nama prosedur dan bentuk parameternya tetap, perubahan struktur tabel cukup ditangani di dalam prosedur. Aplikasi tidak perlu ikut dirilis ulang.
5. Parameter mempersulit penyisipan perintah: masukan yang dikirim sebagai parameter diperlakukan sebagai nilai, bukan sebagai kode yang bisa dieksekusi. Ini menyulitkan upaya SQL injection, meski perlu dicatat bahwa dokumentasi Microsoft memilih kata "mempersulit", bukan "mustahil". Prosedur yang menyusun perintahnya sendiri sebagai teks tetap bisa disusupi.

Kiri, tanpa stored procedure: banyak panah bolak-balik aplikasi ke database. Kanan, dengan stored procedure: satu pasang.

Untuk operasi CRUD yang berulang di banyak tempat, poin kedua dan keempat biasanya yang paling terasa manfaatnya dalam jangka panjang.

Benarkah Stored Procedure Selalu Lebih Cepat?

Alasan yang paling sering disebut untuk memakai stored procedure adalah kecepatan, dengan penjelasan bahwa prosedur sudah dikompilasi lebih dulu. Penjelasan itu benar sebagian, dan dokumentasi Microsoft sendiri menyediakan koreksinya dalam tiga lapis.

Pertama, keunggulannya terletak pada kemudahan pencocokan, bukan pada kompilasi. Teks perintah di dalam sebuah prosedur selalu sama persis setiap kali dijalankan. Karena itulah mesin database mudah mencocokkannya dengan rencana eksekusi yang sudah tersimpan, dan inilah yang disebut dokumentasi Microsoft sebagai keunggulan utamanya atas kumpulan perintah dinamis.

Kedua, query biasa juga mendapat rencana tersimpan. Saat sebuah perintah dijalankan tanpa parameter, SQL Server mengubahnya menjadi berparameter secara internal untuk memperbesar peluang pencocokan. Mekanisme ini disebut simple parameterization, dan ada pula mode PARAMETERIZATION FORCED yang memberlakukannya pada seluruh perintah di sebuah database. Syaratnya, seluruh nama objek harus ditulis lengkap. Perintah SELECT * FROM Person tidak akan cocok, sementara SELECT * FROM Person.Person cocok mulai eksekusi kedua.

Ketiga, rencana yang tersimpan bisa berbalik merugikan. Mesin database mengintip nilai parameter saat pertama kali menyusun rencana, perilaku yang dikenal sebagai parameter sniffing. Rencana yang optimal untuk parameter pertama belum tentu cocok untuk parameter berikutnya. Dokumentasi Microsoft menyatakan bahwa bila terjadi perubahan besar pada tabel atau data yang dirujuk, rencana yang sudah dikompilasi justru dapat membuat prosedur berjalan lebih lambat.

Angka berikut menggambarkan seberapa kasar tebakan mesin database saat ia kehilangan pijakan. Kadang nilai parameter tidak dapat diintip, misalnya karena disimpan lebih dulu di variabel lokal. Bila statistik kolomnya juga tidak tersedia, optimizer jatuh ke tebakan bawaan: 10% selektivitas untuk predikat kesetaraan dan 30% untuk pertidaksamaan atau rentang. Penawarnya adalah petunjuk OPTION (RECOMPILE), yang memaksa penyusunan rencana ulang memakai nilai sesungguhnya.

Kesimpulan praktisnya, stored procedure memang memangkas perjalanan jaringan, dan itu keuntungan nyata. Namun anggapan bahwa ia otomatis mempercepat setiap perintah SQL di dalamnya perlu diletakkan pada tempatnya.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

1. Kode sulit dilacak: prosedur tinggal di dalam database, bukan di repositori kode. Riwayat perubahannya tidak ikut tercatat di version control kecuali tim Anda disiplin mengekspornya ke berkas migrasi. Untuk sekadar mengetahui prosedur mana yang menyentuh sebuah tabel, Anda harus menjalankan query katalog seperti pada bagian sebelumnya.
2. Proses debugging lebih berat: menelusuri kesalahan di dalam prosedur menuntut alat khusus dan hak akses ke database. Tidak ada kemudahan seperti menaruh titik henti di kode aplikasi lalu menjalankannya ulang di komputer sendiri.
3. Tidak portabel antar-database: karena SQL/PSM bersifat opsional, tiap produk menempuh jalannya sendiri. Prosedur MySQL tidak bisa langsung dipindahkan ke SQL Server, dan keduanya berbeda lagi dari PL/SQL milik Oracle. Bahkan bawaan keamanannya berkebalikan: MySQL memakai SQL SECURITY DEFINER sebagai bawaan, sementara PostgreSQL memakai SECURITY INVOKER.
4. Ada batasan yang mengejutkan di tengah jalan: MySQL melarang LOCK TABLES, UNLOCK TABLES, ALTER VIEW, LOAD DATA, dan LOAD XML di dalam rutin tersimpan. Perintah BEGIN di dalam prosedur dibaca sebagai awal blok, bukan awal transaksi, sehingga Anda harus memakai START TRANSACTION, dan itu pun dilarang di dalam function maupun trigger.
5. Bergesekan dengan ORM modern: sebagian besar framework hari ini menyusun query lewat lapisan pemetaan objek. Memasukkan stored procedure ke alur itu berarti menulis jalur khusus yang keluar dari pola pengembangan tim.

Contoh paling gamblang bahwa manfaat stored procedure bergantung pada konteks datang dari SQLite, yang tidak mendukungnya sama sekali. Perintah CREATE PROCEDURE di sana menghasilkan galat sintaks. Di forum resminya, seorang kontributor menjelaskan alasannya dengan lugas. Pada SQLite, database berjalan di dalam proses aplikasi itu sendiri. Karena itu yang disebut stored procedure sesungguhnya hanyalah subrutin biasa milik aplikasi.

Alasan tersebut menunjukkan pokok persoalannya. Keuntungan terbesar stored procedure lahir dari adanya jarak jaringan antara aplikasi dan database. Hilangkan jaraknya, hilang pula alasan utamanya.

Kapan Sebaiknya Anda Memakai Stored Procedure

Pakailah stored procedure ketika minimal salah satu keadaan berikut terpenuhi:

• Satu tugas membutuhkan lebih dari tiga perintah berurutan yang saling bergantung dan harus berhasil atau gagal bersamaan.
• Operasi menyentuh puluhan ribu baris sekaligus, misalnya pembaruan massal atau perhitungan akhir bulan, sehingga memindahkan datanya ke sisi aplikasi jelas boros.
• Ada lebih dari satu aplikasi memakai logika yang sama persis, apalagi bila ditulis dalam bahasa pemrograman berbeda.
• Kebutuhan audit menuntut satu jalur tunggal ke tabel sensitif, dan pengguna tidak boleh menyentuh tabelnya secara langsung.

Sebaliknya, tahan diri dari memakainya bila kondisinya seperti ini:

• Operasinya hanya CRUD sederhana satu tabel, yang justru menambah tempat baru untuk merawat kode.
• Tidak ada satu pun anggota tim yang nyaman membaca SQL prosedural, sehingga prosedur berubah menjadi kotak hitam saat penulisnya pindah.
• Proyek Anda masih mungkin berpindah sistem database dalam beberapa tahun ke depan.

Ada satu hal teknis yang perlu Anda periksa lebih dulu. Membuat prosedur membutuhkan privilese CREATE ROUTINE di MySQL. Di SQL Server, yang dibutuhkan adalah izin CREATE PROCEDURE pada database beserta hak ALTER pada skemanya. Sebagian layanan hosting bersama tidak memberikan privilese tersebut kepada pengguna. Bila akun database Anda terbentur pembatasan itu, jalan keluarnya adalah memakai server dengan kendali penuh seperti VPS Indonesia, atau meminta penyedia hosting membukanya.

Pertanyaan yang Sering Diajukan

Apakah belajar SQL sulit sebelum bisa menulis stored procedure? Tidak, asalkan urutannya benar. Anda cukup menguasai SELECT, INSERT, UPDATE, DELETE, dan JOIN sebelum masuk ke prosedur. Bagian yang benar-benar baru hanyalah variabel, percabangan, dan perulangan, dan ketiganya mirip dengan konsep serupa di bahasa pemrograman mana pun.

Apa itu procedure dalam SQL? Procedure adalah blok perintah SQL bernama yang disimpan di dalam database dan dijalankan lewat panggilan. Istilah "procedure" dan "stored procedure" merujuk pada hal yang sama; kata "stored" menegaskan bahwa blok itu tersimpan di sisi server.

Apakah stored procedure masih relevan hari ini? Masih, tetapi porsinya menyempit. Ia tetap pilihan yang masuk akal untuk pemrosesan data bervolume besar dan untuk pengetatan izin akses. Untuk logika bisnis sehari-hari, sebagian besar tim modern memilih menaruhnya di kode aplikasi agar mudah diuji dan mudah ditelusuri riwayat perubahannya.

Apa bedanya stored procedure dan trigger? Stored procedure dijalankan karena ada yang memanggilnya, sementara trigger berjalan sendiri saat data pada sebuah tabel berubah. Trigger juga tidak menerima parameter dan tidak mengembalikan nilai.

Kesimpulan

Stored procedure adalah kumpulan perintah SQL bernama yang tersimpan di dalam database dan dijalankan dengan satu panggilan, memangkas perjalanan bolak-balik antara aplikasi dan server database. Manfaat terbesarnya muncul pada tugas berlapis yang menyentuh banyak baris, pada logika yang dipakai beberapa aplikasi sekaligus, dan pada pengetatan izin akses ke tabel sensitif.

Sebaliknya, untuk operasi satu tabel yang sederhana dan untuk proyek yang mungkin berpindah sistem database, menaruh logikanya di kode aplikasi biasanya lebih menguntungkan. Perhitungkan juga bahwa kode di dalam database lebih sulit ditelusuri dan diuji dibanding kode di repositori.

Semoga artikel ini membantu.