Sqlserver
 sql >> Teknologi Basis Data >  >> RDS >> Sqlserver

SQL Dinamis vs Prosedur Tersimpan

SQL dinamis dan prosedur tersimpan adalah dua komponen terpenting dari SQL Server. Dalam artikel ini, kita akan melihat kelebihan dan kekurangan masing-masing dan kapan menggunakannya.

Kinerja

Semua orang tahu jawaban untuk pertanyaan ini. Prosedur tersimpan mengalahkan SQL dinamis dalam hal kinerja. Prosedur tersimpan di-cache di memori server dan eksekusinya jauh lebih cepat daripada SQL dinamis. Jika semua variabel yang tersisa tetap konstan, prosedur tersimpan mengungguli SQL dinamis.

Pemisahan Masalah

Dalam hal pemisahan masalah, prosedur tersimpan mengalahkan SQL dinamis.

Prosedur tersimpan memungkinkan Anda untuk menjaga logika database Anda terpisah dari logika bisnis Anda. Oleh karena itu, jika terjadi kesalahan dalam logika bisnis Anda, Anda hanya perlu mengubah kode aplikasi Anda. Sebaliknya, jika ada masalah dengan logika database Anda, hanya prosedur tersimpan Anda yang perlu dimodifikasi. Selain itu, jika prosedur tersimpan diperbarui, kode aplikasi tidak perlu dikompilasi ulang dan disebarkan.

Jika Anda menggunakan kueri SQL dinamis dalam kode klien, Anda harus memperbarui kode aplikasi jika terjadi kesalahan dalam kueri SQL. Ini berarti Anda harus mengkompilasi ulang dan menerapkan kode aplikasi.

Lalu Lintas Jaringan

Prosedur tersimpan menghasilkan lebih sedikit lalu lintas jaringan daripada SQL dinamis karena mengeksekusi prosedur tersimpan hanya memerlukan nama prosedur dan parameter (jika ada) untuk dikirim melalui jaringan.

Menjalankan SQL dinamis memerlukan kueri lengkap untuk dikirim ke seluruh jaringan, meningkatkan lalu lintas jaringan, terutama jika kuerinya sangat besar.

Serangan Injeksi SQL

Prosedur tersimpan tidak rentan terhadap serangan SQL Injection.

Kueri SQL dinamis rentan terhadap serangan injeksi SQL jika kueri berparameter tidak digunakan, dan kueri berparameter tidak dapat digunakan dengan SQL dinamis jika nama tabel atau kolom diteruskan sebagai parameter.

Dalam hal ini, solusinya adalah fungsi nama kode dapat digunakan untuk mencegah serangan injeksi SQL.

Penggunaan kembali Paket Kueri Cached

Prosedur tersimpan meningkatkan kinerja database karena memungkinkan rencana kueri yang di-cache untuk digunakan kembali. Dalam kasus SQL dinamis, Anda harus menggunakan kueri berparameter untuk meningkatkan penggunaan kembali rencana kueri yang di-cache. Dengan tidak adanya rencana kueri berparameter, server SQL secara otomatis mendeteksi parameter dan menghasilkan rencana kueri yang di-cache yang menghasilkan peningkatan kinerja.

Penting untuk disebutkan di sini bahwa hanya sistem OLTP yang mendapat manfaat dari penggunaan kembali rencana kueri yang di-cache. Dalam hal sistem OLAP, pilihan pengoptimal berubah, sistem OLAP mendapat manfaat dari paket unik.

Pemeliharaan

Prosedur tersimpan dengan SQL statis lebih mudah dipelihara. Misalnya, dalam kasus SQL statis dalam prosedur tersimpan, kesalahan sintaks dapat ditangkap sebelum dijalankan. Dalam kasus SQL dinamis di dalam prosedur tersimpan, kesalahan sintaks tidak dapat ditangkap sebelum eksekusi kueri.

Selanjutnya, prosedur tersimpan lebih seperti fungsi, mereka didefinisikan sekali dan kemudian dapat dipanggil di mana saja dalam skrip. Oleh karena itu, jika Anda ingin memperbarui prosedur tersimpan, Anda hanya perlu memperbaruinya di satu tempat. Semua bagian aplikasi yang memanggil prosedur tersimpan akan memiliki akses ke versi yang diperbarui. Namun, kelemahannya adalah bagian aplikasi tersebut juga dapat terpengaruh jika Anda tidak ingin prosedur tersimpan yang diperbarui. Dalam kasus SQL dinamis, Anda mungkin harus menulis skrip SQL di banyak tempat, tetapi dalam kasus seperti itu, memperbarui skrip di satu tempat tidak memengaruhi yang lain. Keputusan antara menggunakan prosedur tersimpan dan SQL dinamis bergantung pada fungsionalitas aplikasi.

Keamanan

Jika beberapa aplikasi mengakses database, lebih aman menggunakan prosedur tersimpan daripada SQL dinamis.

Prosedur tersimpan memberikan lapisan keamanan ekstra, sedangkan konteks pengguna adalah satu-satunya cara untuk mengontrol izin pada skrip SQL dinamis. Secara keseluruhan, mengamankan SQL dinamis sulit dibandingkan dengan prosedur tersimpan.

Mengidentifikasi Dependensi

Dalam database relasional, tabel memiliki ketergantungan pada tabel lain dalam database.

Pertimbangkan skenario di mana Anda ingin menghapus tabel tetapi, sebelum melakukannya, Anda ingin mengetahui semua dependensi tabel. Atau dalam istilah sederhana, Anda ingin menemukan kueri yang mengakses tabel yang ingin Anda hapus. Dalam kasus ini, Anda dapat menggunakan prosedur tersimpan sp_depends.

Namun, sp_depends hanya dapat mendeteksi dependensi di mana SQL statis digunakan di dalam prosedur tersimpan. Dalam kasus SQL dinamis yang bergantung pada tabel, ketergantungan itu tidak dapat dideteksi oleh prosedur tersimpan sp_depends. Mari kita lihat ini dalam tindakan dengan bantuan contoh sederhana.

Menyiapkan Data Dummy

Mari kita buat beberapa data dummy untuk membantu menjelaskan konsep dependensi dalam SQL statis dan dinamis.

CREATE DATABASE deptest;USE deptestCREATE TABLE student( Id int identitas primary key, Nama VARCHAR(50) NOT NULL, Gender VARCHAR(50) NOT NULL, Age int)INSERT INTO studentVALUES('James', 'Male', 20 ),('Helene', 'Wanita', 20),('Sofia', 'Wanita', 20),('Ed', 'Pria', 20),('Ron', 'Wanita', 20) 

Sekarang kita memiliki database pengujian yang berisi tabel dan beberapa data pengujian. Sekarang mari kita buat dua prosedur tersimpan yang mengakses tabel siswa.

Prosedur tersimpan pertama menggunakan SQL statis untuk mengambil semua catatan dari tabel siswa:

GUNAKAN deptestGOCREATE PROC spStatProcASBEGIN SELECT * FROM studentEND

Jalankan skrip di atas. Skrip ini membuat prosedur tersimpan “spStatProc” di dalam database terdalam.

Mari buat prosedur tersimpan lain yang berisi SQL dinamis yang mengambil semua record dari tabel siswa.

GUNAKAN deptestGOCREATE PROC spDynProcASBEGIN DECLARE @query NVARCHAR(100) SET @query ='SELECT * FROM student' EXECUTE sp_execute @query END

Skrip ini membuat prosedur tersimpan "spDynProc" di dalam database terdalam. Prosedur tersimpan ini menggunakan pernyataan SQL dinamis untuk mengambil semua record dari tabel siswa.

Sekarang kami memiliki dua prosedur tersimpan yang memiliki ketergantungan pada tabel siswa. Salah satunya berisi SQL statis dan yang lainnya berisi SQL dinamis.

Namun, jika Anda menjalankan prosedur tersimpan sp_depends dan meneruskannya ke tabel siswa sebagai parameter, Anda akan melihat bahwa itu hanya akan mengambil prosedur tersimpan "spStatProc". Ini karena berisi SQL statis. Prosedur tersimpan “spDynProc” akan diabaikan karena berisi SQL dinamis.

Jalankan script berikut.

GUNAKAN siswa deptestGOEXECUTE sp_depends

Ini akan mendapatkan output berikut:

[id tabel=40 /]

Anda dapat melihat bahwa sp_depends tidak dapat melaporkan dependensi “spDynProc” dan hanya melaporkan “spStatProc”.

Kompleksitas

Prosedur tersimpan bisa menjadi sangat rumit jika Anda menggunakan filter dalam jumlah besar dan ada beberapa klausa AND dan OR di antara filter. Di sisi lain, menggunakan SQL dinamis Anda dapat secara dinamis menghasilkan klausa WHERE tergantung pada jenis filter. Hal ini membuat SQL dinamis menjadi pilihan yang lebih baik jika Anda ingin menerapkan logika yang sangat kompleks.

Kesimpulan

Secara keseluruhan, prosedur tersimpan mengungguli SQL dinamis di hampir semua aspek. Mereka lebih cepat, aman, dan mudah dirawat, serta membutuhkan lebih sedikit lalu lintas jaringan. Sebagai aturan praktis, prosedur tersimpan harus digunakan dalam skenario di mana Anda tidak perlu mengubah kueri dan kueri Anda tidak terlalu rumit. Namun, jika Anda sering mengubah nama tabel, nama kolom, atau jumlah parameter dalam kueri Anda, SQL Dinamis adalah pilihan yang lebih baik karena strategi penerapannya yang lebih sederhana.

Tautan Berguna

  • SQL Dinamis versus Prosedur Tersimpan
  • Jangan takut SQL Dinamis
  • Membangun prosedur tersimpan berkinerja tinggi
  • Kelas tentang Prosedur Tersimpan

  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Dapatkan Zona Waktu Saat Ini dari Server di SQL Server (T-SQL)

  2. Pandangan Pertama pada Penaksir Kardinalitas SQL Server Baru

  3. Alat Manajemen SQL Server 2017

  4. Parsing string yang dipisahkan koma untuk membuat IN Daftar string dalam klausa Where

  5. Kemungkinan Cara untuk Memperbaiki Masalah Korupsi Metadata SQL Server