Apa pro dan kontra untuk menjaga SQL di Stored Procs versus Code [ditutup]

Apa keuntungan / kerugian dari menjaga SQL dalam kode sumber C # Anda atau dalam Procs Tersimpan? Saya telah mendiskusikan hal ini dengan seorang teman di proyek sumber terbuka yang sedang kami kerjakan (C # ASP.NET Forum). Saat ini, sebagian besar akses database dilakukan dengan membangun inline SQL di C # dan memanggil ke SQL Server DB. Jadi saya mencoba menentukan mana, untuk proyek khusus ini, yang terbaik.

Sejauh ini saya punya:

Keuntungan dalam Kode:

• Lebih mudah dikelola - tidak perlu menjalankan skrip SQL untuk memperbarui kueri
• Lebih mudah untuk port ke DB lain - tidak ada procs ke port

Keuntungan untuk Procs Tersimpan:

• Performa
• Keamanan

Saya bukan penggemar prosedur yang tersimpan

Prosedur Tersimpan LEBIH dapat dipertahankan karena: * Anda tidak perlu mengkompilasi ulang aplikasi C # kapan pun Anda ingin mengubah beberapa SQL

Anda akan tetap mengkompilasi ulang ketika tipe data berubah, atau Anda ingin mengembalikan kolom tambahan, atau apa pun. Frekuensi Anda dapat 'secara transparan' mengubah SQL keluar dari bawah aplikasi Anda cukup kecil secara keseluruhan

• Anda akhirnya menggunakan kembali kode SQL.

Bahasa pemrograman, termasuk C #, memiliki hal yang luar biasa ini, yang disebut fungsi. Ini berarti Anda dapat menjalankan blok kode yang sama dari berbagai tempat! Luar biasa! Anda kemudian dapat memasukkan kode SQL yang dapat digunakan kembali di dalam salah satu dari ini, atau jika Anda ingin mendapatkan teknologi yang sangat tinggi, Anda dapat menggunakan perpustakaan yang melakukannya untuk Anda. Saya percaya mereka disebut Object Relational Mappers, dan sangat umum akhir-akhir ini.

Pengulangan kode adalah hal terburuk yang dapat Anda lakukan ketika Anda mencoba membangun aplikasi yang bisa dirawat!

Setuju, itulah sebabnya disimpanprocs adalah hal yang buruk. Jauh lebih mudah untuk melakukan refactor dan mendekomposisi (memecah menjadi bagian-bagian kecil) kode menjadi fungsi daripada SQL menjadi ... blok SQL?

Anda memiliki 4 server web dan banyak aplikasi windows yang menggunakan kode SQL yang sama. Sekarang Anda menyadari ada masalah kecil dengan kode SQl, jadi Anda lebih suka ...... mengubah proc di 1 tempat atau mendorong kode ke semua server web, instal ulang semua aplikasi desktop (clickonce mungkin membantu) pada semua kotak windows

Mengapa aplikasi windows Anda terhubung langsung ke database pusat? Itu tampak seperti lubang keamanan BESAR di sana, dan hambatan karena mengesampingkan caching sisi server. Bukankah mereka harus terhubung melalui layanan web atau mirip dengan server web Anda?

Jadi, dorong 1 sproc baru, atau 4 server web baru?

Dalam hal ini lebih mudah untuk mendorong satu sproc baru, tetapi dalam pengalaman saya, 95% dari 'perubahan yang didorong' mempengaruhi kode dan bukan database. Jika Anda mendorong 20 hal ke server web bulan itu, dan 1 ke database, Anda tidak akan kehilangan banyak jika Anda mendorong 21 hal ke server web, dan nol ke database.

Kode lebih mudah ditinjau.

Bisakah Anda menjelaskan caranya? Saya tidak mengerti. Terutama melihat sebagai sprocs mungkin tidak dalam kontrol sumber, dan karena itu tidak dapat diakses melalui browser SCM berbasis web dan sebagainya.

Lebih banyak kontra:

Storedprocs hidup dalam database, yang muncul di dunia luar sebagai kotak hitam. Hal-hal sederhana seperti ingin menempatkan mereka dalam kendali sumber menjadi mimpi buruk.

Ada juga masalah upaya belaka. Mungkin masuk akal untuk memecah semuanya menjadi satu juta tingkatan jika Anda mencoba untuk membenarkan kepada CEO Anda mengapa hanya menghabiskan 7 juta dolar untuk membangun beberapa forum, tetapi jika tidak, membuat proksi yang disimpan untuk setiap hal kecil hanya pekerjaan tambahan tanpa kerjaan manfaat.

Ini sedang dibahas pada beberapa utas lainnya di sini saat ini. Saya adalah pendukung yang konsisten dari prosedur tersimpan, meskipun beberapa argumen yang baik untuk Linq ke Sql sedang disajikan.

Menanamkan pertanyaan dalam kode Anda akan membuat Anda lebih dekat dengan model data Anda. Prosedur tersimpan adalah bentuk pemrograman kontraktual yang baik, artinya DBA memiliki kebebasan untuk mengubah model data dan kode dalam prosedur, selama kontrak yang diwakili oleh input dan output prosedur tersimpan disimpan.

Menyetel basis data produksi bisa sangat sulit ketika kueri terkubur dalam kode dan bukan di satu pusat, lokasi yang mudah dikelola.

[Sunting] Ini diskusi lain saat ini

Menurut pendapat saya, Anda tidak dapat memilih ya atau tidak pada pertanyaan ini. Ini benar-benar tergantung pada desain aplikasi Anda.

Saya benar-benar menentang penggunaan SP di lingkungan 3-tier, di mana Anda memiliki server aplikasi di depan. Dalam lingkungan seperti ini server aplikasi Anda ada untuk menjalankan logika bisnis Anda. Jika Anda juga menggunakan SP Anda mulai mendistribusikan implementasi logika bisnis Anda di seluruh sistem Anda dan itu akan menjadi sangat tidak jelas siapa yang bertanggung jawab untuk apa. Akhirnya Anda akan berakhir dengan server aplikasi yang pada dasarnya tidak melakukan apa-apa selain yang berikut ini:

(Pseudocode)

Function createOrder(Order yourOrder) 
Begin
  Call SP_createOrder(yourOrder)
End

Jadi pada akhirnya Anda memiliki tingkat menengah Anda berjalan di 4 Server cluster yang sangat keren ini masing-masing dilengkapi dengan 16 CPU dan itu benar-benar tidak akan melakukan apa-apa sama sekali! Sayang sekali!

Jika Anda memiliki klien gui gemuk yang langsung terhubung ke DB Anda atau mungkin lebih banyak aplikasi, itu cerita yang berbeda. Dalam situasi ini SP dapat berfungsi sebagai semacam tingkat menengah semu yang memisahkan aplikasi Anda dari model data dan menawarkan akses yang dapat dikontrol.

Keuntungan dalam Kode:

• Lebih mudah dikelola - tidak perlu menjalankan skrip SQL untuk memperbarui kueri
• Lebih mudah untuk port ke DB lain - tidak ada procs ke port

Sebenarnya, saya pikir Anda memilikinya mundur. IMHO, SQL dalam kode sulit untuk dirawat karena:

• Anda akhirnya mengulangi diri Anda di blok kode terkait
• SQL tidak didukung sebagai bahasa di banyak IDE sehingga Anda hanya memiliki serangkaian string un-error check yang melakukan tugas untuk Anda
• perubahan tipe data, nama tabel atau kendala jauh lebih umum daripada mengganti seluruh database untuk yang baru
• tingkat kesulitan Anda meningkat saat kueri Anda tumbuh dalam kompleksitas
• dan menguji permintaan inline membutuhkan pembangunan proyek

Anggap Procs Tersimpan sebagai metode yang Anda panggil dari objek basis data - mereka jauh lebih mudah digunakan kembali, hanya ada satu tempat untuk mengedit dan jika Anda mengubah penyedia DB, perubahan itu terjadi pada Procs Tersimpan Anda dan tidak dalam kode Anda .

Yang mengatakan, keuntungan kinerja procs yang disimpan adalah minimal seperti yang dikatakan Stu sebelum saya dan Anda tidak dapat menempatkan titik istirahat dalam prosedur yang tersimpan (belum).

MENIPU

Saya menemukan bahwa melakukan banyak pemrosesan di dalam prosedur tersimpan akan membuat server DB Anda menjadi satu titik tidak fleksibel, dalam hal meningkatkan tindakan Anda.

Namun melakukan semua itu dalam program Anda sebagai lawan dari sql-server, mungkin memungkinkan Anda untuk meningkatkan skala jika Anda memiliki beberapa server yang menjalankan kode Anda. Tentu saja ini tidak berlaku untuk procs yang disimpan yang hanya mengambil atau memperbarui normal tetapi untuk orang-orang yang melakukan lebih banyak pengolahan seperti perulangan kumpulan data.

PROS

1. Performa untuk apa nilainya (menghindari permintaan parsing oleh driver DB / paket rekreasi dll)
2. Manipulasi data tidak tertanam dalam kode C / C ++ / C # yang berarti saya memiliki kode tingkat lebih rendah untuk melihat. SQL kurang bertele-tele dan lebih mudah dilihat ketika dicantumkan secara terpisah.
3. Karena pemisahan orang dapat menemukan dan menggunakan kembali kode SQL lebih mudah.
4. Lebih mudah untuk mengubah hal-hal ketika skema berubah - Anda hanya perlu memberikan output yang sama dengan kode dan itu akan berfungsi dengan baik
5. Lebih mudah untuk port ke database yang berbeda.
6. Saya dapat mendaftar izin individu pada prosedur tersimpan saya dan mengontrol akses di tingkat itu juga.
7. Saya dapat membuat profil kueri data / kode kegigihan saya terpisah dari kode transformasi data saya.
8. Saya dapat menerapkan kondisi yang dapat diubah dalam prosedur tersimpan saya dan akan mudah untuk menyesuaikannya di situs pelanggan.
9. Menjadi lebih mudah untuk menggunakan beberapa alat otomatis untuk mengkonversi skema dan pernyataan saya bersama daripada ketika itu tertanam di dalam kode saya di mana saya harus memburu mereka.
10. Memastikan praktik terbaik untuk akses data lebih mudah ketika Anda memiliki semua kode akses data di dalam satu file - Saya dapat memeriksa pertanyaan yang mengakses tabel non-performant atau yang menggunakan tingkat serialisasi yang lebih tinggi atau memilih * dalam kode, dll. .
11. Menjadi lebih mudah untuk menemukan perubahan skema / perubahan logika manipulasi data ketika semuanya terdaftar dalam satu file.
12. Menjadi lebih mudah untuk melakukan pencarian dan mengganti suntingan pada SQL ketika mereka berada di tempat yang sama misalnya mengubah / menambahkan pernyataan isolasi transaksi untuk semua procs yang disimpan.
13. Saya dan orang DBA menemukan bahwa memiliki file SQL terpisah lebih mudah / nyaman ketika DBA harus meninjau hal-hal SQL saya.
14. Terakhir, Anda tidak perlu khawatir tentang serangan injeksi SQL karena beberapa anggota tim Anda yang malas tidak menggunakan kueri parametrized saat menggunakan sqls yang disematkan.

Keuntungan kinerja untuk prosedur tersimpan sering diabaikan.

Lebih banyak keuntungan untuk prosedur tersimpan:

• Cegah rekayasa balik (jika dibuat dengan Enkripsi, tentu saja)
• Sentralisasi akses basis data yang lebih baik
• Kemampuan untuk mengubah model data secara transparan (tanpa harus menggunakan klien baru); sangat berguna jika beberapa program mengakses model data yang sama

Saya jatuh di sisi kode . Kami membangun lapisan akses data yang digunakan oleh semua aplikasi (baik web dan klien), jadi KERING dari perspektif itu. Ini menyederhanakan penyebaran database karena kita hanya perlu memastikan skema tabel sudah benar. Ini menyederhanakan pemeliharaan kode karena kita tidak perlu melihat kode sumber dan basis data.

Saya tidak punya banyak masalah dengan kopling ketat dengan model data karena saya tidak melihat di mana dimungkinkan untuk benar-benar memutuskan kopling itu. Aplikasi dan datanya secara inheren digabungkan.

Prosedur tersimpan.

Jika kesalahan terpeleset atau logika sedikit berubah, Anda tidak perlu mengkompilasi ulang proyek. Plus, ini memungkinkan akses dari berbagai sumber, bukan hanya satu tempat Anda mengkodekan kueri dalam proyek Anda.

Saya tidak berpikir itu lebih sulit untuk mempertahankan prosedur yang tersimpan, Anda tidak boleh kode secara langsung dalam database tetapi dalam file terpisah terlebih dahulu, maka Anda bisa menjalankannya pada DB apa pun yang Anda perlu set-up.

Keuntungan untuk prosedur Tersimpan :

Kode lebih mudah ditinjau.

Kurang berpasangan, oleh karena itu lebih mudah diuji.

Lebih mudah disetel.

Kinerja umumnya lebih baik, dari sudut pandang lalu lintas jaringan - jika Anda memiliki kursor, atau serupa, maka tidak ada beberapa perjalanan ke database

Anda dapat melindungi akses ke data dengan lebih mudah, menghapus akses langsung ke tabel, menegakkan keamanan melalui procs - ini juga memungkinkan Anda untuk menemukan relatif cepat setiap kode yang memperbarui tabel.

Jika ada layanan lain yang terlibat (seperti layanan Pelaporan), Anda mungkin merasa lebih mudah untuk menyimpan semua logika Anda dalam prosedur tersimpan, daripada dalam kode, dan harus menduplikatnya

Kekurangan:

Lebih sulit dikelola untuk pengembang: kontrol versi skrip: apakah semua orang memiliki database sendiri, apakah sistem kontrol versi terintegrasi dengan database dan IDE?

Dalam beberapa keadaan, kode sql yang dibuat secara dinamis dapat memiliki kinerja yang lebih baik daripada proc yang disimpan. Jika Anda telah membuat proc tersimpan (misalkan sp_customersearch) yang menjadi sangat rumit dengan puluhan parameter karena itu harus sangat fleksibel, Anda mungkin dapat menghasilkan pernyataan sql yang lebih sederhana dalam kode saat runtime.

Orang bisa berpendapat bahwa ini hanya memindahkan beberapa pemrosesan dari SQL ke server web, tetapi secara umum itu akan menjadi hal yang baik.

Hal hebat lainnya tentang teknik ini adalah bahwa jika Anda mencari dalam profiler SQL, Anda dapat melihat kueri yang Anda buat dan men-debug lebih mudah daripada melihat panggilan proc yang tersimpan dengan 20 parameter masuk.

Saya suka procs tersimpan, tidak tahu berapa kali saya bisa membuat perubahan ke aplikasi menggunakan prosedur tersimpan yang tidak menghasilkan downtime ke aplikasi.

Penggemar besar Transact SQL, menyetel kueri besar telah terbukti sangat berguna bagi saya. Belum menulis inline SQL dalam waktu sekitar 6 tahun!

Anda mencantumkan 2 pro-poin untuk sprocs:

Kinerja - tidak juga. Di Sql 2000 atau lebih besar optimisasi rencana kueri cukup bagus, dan di-cache. Saya yakin bahwa Oracle dll melakukan hal serupa. Saya tidak berpikir ada kasus untuk sprocs untuk kinerja lagi.

Keamanan? Mengapa sprocs lebih aman? Kecuali Anda memiliki basis data yang cukup tidak aman, semua akses akan berasal dari DBA Anda atau melalui aplikasi Anda. Selalu pisahkan semua pertanyaan - jangan pernah menyisihkan sesuatu dari input pengguna dan Anda akan baik-baik saja.

Itu praktik terbaik untuk kinerja.

Linq jelas merupakan cara saya menjalankan proyek baru sekarang. Lihat posting serupa ini .

@Keith

Keamanan? Mengapa sprocs lebih aman?

Seperti yang disarankan oleh Komradekatz, Anda dapat melarang akses ke tabel (untuk kombo nama pengguna / kata sandi yang terhubung ke DB) dan hanya mengizinkan akses SP. Dengan begitu jika seseorang mendapatkan nama pengguna dan kata sandi ke database Anda, mereka dapat menjalankan SP tetapi tidak dapat mengakses tabel atau bagian lain dari DB.

(Tentu saja mengeksekusi sprocs dapat memberi mereka semua data yang mereka butuhkan tetapi itu akan tergantung pada sprocs yang tersedia. Memberi mereka akses ke tabel memberi mereka akses ke semuanya.)

Pikirkan seperti ini

Anda memiliki 4 server web dan banyak aplikasi windows yang menggunakan kode SQL yang sama. Sekarang Anda menyadari ada masalah kecil dengan kode SQl, jadi Anda lebih suka ...... mengubah proc di 1 tempat atau mendorong kode ke semua server web, instal ulang semua aplikasi desktop (clickonce mungkin membantu) pada semua kotak windows

Saya lebih suka procs yang disimpan

Juga lebih mudah untuk melakukan pengujian kinerja terhadap suatu proc, memasukkannya ke dalam query analyzer set statistics io / time pada set showplan_text on dan voila

tidak perlu menjalankan profiler untuk melihat apa yang sedang dipanggil

hanya 2 sen saya

Saya lebih suka menyimpannya dalam kode (menggunakan ORM, bukan inline atau ad-hoc) sehingga mereka dilindungi oleh kontrol sumber tanpa harus berurusan dengan menyimpan file .sql.

Selain itu, prosedur tersimpan tidak inheren lebih aman. Anda dapat menulis kueri buruk dengan sproc semudah inline. Kueri inline yang diparameterisasi dapat sama amannya dengan sproc.

Gunakan kode aplikasi Anda sebagai yang terbaik: menangani logika.
Gunakan basis data Anda untuk yang terbaik: simpan data.

Anda dapat men-debug prosedur yang tersimpan tetapi Anda akan menemukan lebih mudah untuk men-debug dan mempertahankan logika dalam kode. Biasanya Anda akan mengakhiri kompilasi ulang kode Anda setiap kali Anda mengubah model database.

Prosedur yang tersimpan juga dengan parameter pencarian opsional sangat tidak efisien karena Anda harus menentukan terlebih dahulu semua parameter yang mungkin dan pencarian kompleks kadang-kadang tidak mungkin karena Anda tidak dapat memprediksi berapa kali suatu parameter akan diulang dalam pencarian.

Ketika datang ke keamanan, prosedur tersimpan jauh lebih aman. Beberapa orang berpendapat bahwa semua akses akan tetap melalui aplikasi. Hal yang dilupakan banyak orang adalah bahwa sebagian besar pelanggaran keamanan berasal dari dalam perusahaan. Pikirkan tentang berapa banyak pengembang yang tahu nama pengguna dan kata sandi "tersembunyi" untuk aplikasi Anda?

Juga, seperti yang ditunjukkan MatthieuF, kinerja dapat lebih ditingkatkan karena lebih sedikit perjalanan pulang pergi antara aplikasi (apakah itu di desktop atau server web) dan server database.

Dalam pengalaman saya, abstraksi model data melalui prosedur tersimpan juga sangat meningkatkan rawatan. Sebagai seseorang yang harus memelihara banyak basis data di masa lalu, sangat melegakan ketika dihadapkan dengan perubahan model yang diperlukan untuk dapat dengan mudah mengubah satu atau dua prosedur yang tersimpan dan membuat perubahan tersebut sepenuhnya transparan untuk SEMUA aplikasi luar. Banyak kali aplikasi Anda bukan satu-satunya yang menunjuk pada basis data - ada aplikasi lain, solusi pelaporan, dll. Jadi melacak semua titik yang terkena dampak dapat menjadi masalah dengan akses terbuka ke tabel.

Saya juga akan meletakkan cek di kolom plus untuk meletakkan pemrograman SQL di tangan mereka yang berspesialisasi di dalamnya, dan untuk SP membuatnya lebih mudah untuk mengisolasi dan menguji / mengoptimalkan kode.

Satu-satunya kelemahan yang saya lihat adalah bahwa banyak bahasa tidak mengizinkan lewatnya parameter tabel, jadi memberikan nilai data angka yang tidak diketahui dapat mengganggu, dan beberapa bahasa masih tidak dapat menangani pengambilan beberapa hasil dari satu prosedur tersimpan (meskipun yang terakhir tidak membuat SPs lebih buruk daripada SQL inline dalam hal itu).

Salah satu saran dari sesi Microsoft TechEd tentang keamanan yang saya hadiri, untuk melakukan semua panggilan melalui procs yang disimpan dan menolak akses langsung ke tabel. Pendekatan ini disebut sebagai memberikan keamanan tambahan. Saya tidak yakin apakah itu layak hanya untuk keamanan, tetapi jika Anda sudah menggunakan procs yang disimpan, tidak ada salahnya.

Pasti lebih mudah dirawat jika Anda memasukkannya ke dalam prosedur tersimpan. Jika ada logika sulit yang terlibat yang berpotensi berubah di masa depan, ide yang baik untuk dimasukkan ke dalam basis data ketika Anda memiliki banyak klien yang terhubung. Sebagai contoh, saya sedang mengerjakan aplikasi saat ini yang memiliki antarmuka pengguna akhir dan aplikasi desktop administratif, yang keduanya berbagi basis data (jelas) dan saya mencoba untuk menjaga logika sebanyak mungkin pada basis data. Ini adalah contoh sempurna dari prinsip KERING .

Saya tegas di sisi procs yang disimpan dengan asumsi Anda tidak curang dan menggunakan SQL dinamis dalam proc yang disimpan. Pertama, menggunakan procs yang disimpan memungkinkan dba untuk mengatur izin pada level proc yang disimpan dan bukan pada level tabel. Ini sangat penting tidak hanya untuk memerangi attacts injeksi SQL tetapi untuk mencegah orang dalam mengakses langsung database dan mengubah hal-hal. Ini adalah cara untuk membantu mencegah penipuan. Tidak ada database yang berisi informasi pribadi (SSN, nomor kartu kredit, dll) atau yang dengan cara apa pun menciptakan transaksi keuangan harus diakses kecuali melalui prosedur yang terstruktur. Jika Anda menggunakan metode lain, Anda membiarkan basis data terbuka lebar bagi individu di perusahaan untuk membuat transaksi keuangan palsu atau mencuri data yang dapat digunakan untuk pencurian identitas.

Procs yang disimpan juga jauh lebih mudah untuk dipelihara dan kinerja dibandingkan dengan SQL yang dikirim dari aplikasi. Mereka juga memungkinkan dba cara untuk melihat apa dampak dari perubahan struktural database akan memiliki cara data diakses. Saya belum pernah bertemu dba yang baik yang akan memungkinkan akses dinamis ke database.

Kami menggunakan prosedur tersimpan dengan Oracle DB di mana saya bekerja sekarang. Kami juga menggunakan Subversi. Semua prosedur tersimpan dibuat sebagai file .pkb & .pks dan disimpan dalam Subversion. Saya sudah melakukan in-line SQL sebelumnya dan itu menyebalkan! Saya lebih suka cara kita melakukannya di sini. Membuat dan menguji prosedur tersimpan yang baru jauh lebih mudah daripada melakukannya dalam kode Anda.

Ada

Log yang lebih kecil

Pro kecil lain untuk prosedur tersimpan yang belum disebutkan: ketika datang ke lalu lintas SQL, akses data berbasis-sp menghasilkan lebih sedikit lalu lintas. Ini menjadi penting ketika Anda memonitor lalu lintas untuk analisis dan profil - log akan jauh lebih kecil dan dapat dibaca.

Saya bukan penggemar prosedur tersimpan, tetapi saya menggunakannya dalam satu kondisi:

Ketika kueri sangat besar, lebih baik menyimpannya dalam database sebagai prosedur tersimpan daripada mengirimnya dari kode. Dengan begitu, alih-alih mengirim sejumlah besar karakter string dari server aplikasi ke basis data, hanya "EXEC SPNAME"perintah yang akan dikirim.

Ini berlebihan ketika server database dan server web tidak berada di jaringan yang sama (Misalnya, komunikasi internet). Dan bahkan jika itu tidak terjadi, terlalu banyak stres berarti banyak bandwidth terbuang sia-sia.

Tapi kawan, mereka sangat buruk untuk dikelola. Saya menghindari mereka sebanyak yang saya bisa.

Proc tersimpan SQL tidak meningkatkan kinerja kueri

Yah jelas menggunakan prosedur tersimpan memiliki beberapa keunggulan dibandingkan membangun SQL dalam kode.

1. Implementasi kode Anda dan SQL menjadi independen satu sama lain.
2. Kode lebih mudah dibaca.
3. Menulis sekali pakai berkali-kali.
4. Ubah sekali
5. Tidak perlu memberikan detail internal kepada programmer tentang database. dll, dll.

Prosedur Tersimpan LEBIH dapat dirawat karena:

• Anda tidak perlu mengkompilasi ulang aplikasi C # kapan pun Anda ingin mengubah beberapa SQL
• Anda akhirnya menggunakan kembali kode SQL.

Pengulangan kode adalah hal terburuk yang dapat Anda lakukan ketika Anda mencoba membangun aplikasi yang bisa dirawat!

Apa yang terjadi ketika Anda menemukan kesalahan logika yang perlu diperbaiki di banyak tempat? Anda lebih cenderung lupa mengubah tempat terakhir tempat Anda menyalin & menempelkan kode Anda.

Menurut pendapat saya, keuntungan kinerja & keamanan merupakan nilai tambah. Anda masih dapat menulis prosedur tersimpan SQL tidak aman / tidak efisien.

Lebih mudah untuk port ke DB lain - tidak ada procs ke port

Tidak terlalu sulit untuk skrip semua prosedur tersimpan Anda untuk pembuatan di DB lain. Bahkan - lebih mudah daripada mengekspor tabel Anda karena tidak ada kunci utama / asing yang perlu dikhawatirkan.

@Terrapin - sprocs sama rentan terhadap serangan injeksi. Seperti yang saya katakan:

Selalu pisahkan semua pertanyaan - jangan pernah menyisihkan sesuatu dari input pengguna dan Anda akan baik-baik saja.

Itu berlaku untuk sprocs dan Sql dinamis.

Saya tidak yakin tidak mengkompilasi ulang aplikasi Anda. Maksud saya, Anda telah menjalankan tes unit Anda terhadap kode itu (baik aplikasi dan DB) sebelum ditayangkan lagi.

@ Beli - ya Anda benar, sprocs membiarkan Anda mengontrol pengguna aplikasi sehingga mereka hanya dapat melakukan sproc, bukan tindakan yang mendasarinya.

Pertanyaan saya adalah: jika semua mengaksesnya melalui aplikasi Anda, menggunakan koneksi dan pengguna dengan hak terbatas untuk memperbarui / menyisipkan dll, apakah level tambahan ini menambah keamanan atau administrasi tambahan?

Pendapat saya sangat yang terakhir. Jika mereka telah mengkompromikan aplikasi Anda ke titik di mana mereka dapat menulis ulang, mereka memiliki banyak serangan lain yang dapat mereka gunakan.

Sql suntikan masih dapat dilakukan terhadap sprocs tersebut jika secara dinamis sebaris kode, sehingga aturan emas masih berlaku, semua input pengguna harus selalu parametris.

Sesuatu yang belum saya lihat sebutkan sejauh ini: orang-orang yang paling tahu database tidak selalu orang-orang yang menulis kode aplikasi. Prosedur yang tersimpan memberi orang-orang basis data cara untuk berinteraksi dengan programmer yang tidak benar-benar ingin belajar banyak tentang SQL. Basis data yang besar - dan terutama warisan - bukan hal termudah untuk dipahami sepenuhnya, sehingga programmer mungkin hanya lebih suka antarmuka sederhana yang memberi mereka apa yang mereka butuhkan: biarkan para DBA mencari cara untuk bergabung dengan 17 tabel untuk mewujudkannya.

Karena itu, bahasa yang digunakan untuk menulis prosedur tersimpan (PL / SQL menjadi contoh terkenal) sangat brutal. Mereka biasanya tidak menawarkan apa pun yang Anda lihat dalam bahasa populer imperatif, OOP, atau fungsional saat ini. Pikirkan COBOL.

Jadi, tetap berpegang pada prosedur tersimpan yang hanya mengaburkan detail relasional daripada yang mengandung logika bisnis.

Saya biasanya menulis kode OO. Saya menduga sebagian besar dari Anda mungkin juga demikian. Dalam konteks itu, tampak jelas bagi saya bahwa semua logika bisnis - termasuk query SQL - termasuk dalam definisi kelas. Memisahkan logika sedemikian rupa sehingga sebagian berada di dalam model objek dan sebagian lagi di dalam basis data tidak lebih baik daripada menempatkan logika bisnis ke dalam antarmuka pengguna.

Banyak yang telah dikatakan dalam jawaban sebelumnya tentang manfaat keamanan dari procs yang disimpan. Ini termasuk dalam dua kategori besar:

1) Membatasi akses langsung ke data. Ini jelas penting dalam beberapa kasus dan, ketika Anda menjumpai satu, procs yang disimpan cukup banyak pilihan Anda. Namun, dalam pengalaman saya, kasus-kasus seperti itu merupakan perkecualian daripada aturan.

2) SQL injection / query parametrized. Keberatan ini adalah herring merah. SQL Inline - bahkan SQL inline yang dihasilkan secara dinamis - dapat sama parametrizednya dengan semua proc yang tersimpan dan dapat dilakukan dengan mudah dalam bahasa modern mana pun yang berharga. Tidak ada keuntungan di sini. ("Pengembang malas mungkin tidak repot-repot menggunakan parameter" bukan keberatan yang valid. Jika Anda memiliki pengembang di tim Anda yang lebih suka menggabungkan data pengguna ke dalam SQL mereka daripada menggunakan parameter, pertama-tama Anda mencoba mengedukasi mereka, lalu Anda memecat mereka. jika itu tidak berhasil, sama seperti yang Anda lakukan dengan pengembang yang memiliki kebiasaan buruk lainnya yang terbukti merugikan.)

Saya adalah pendukung besar kode di atas SPROC. Alasan nomor satu adalah menjaga kode tetap berpasangan, lalu tutup kedua adalah kemudahan kontrol sumber tanpa banyak utilitas khusus untuk menariknya.

Dalam DAL kami jika kami memiliki pernyataan SQL yang sangat kompleks, kami biasanya memasukkannya sebagai file sumber daya dan memperbaruinya sesuai kebutuhan (ini bisa berupa rakitan terpisah juga, dan bertukar per db, dll ...).

Ini menjaga kode kami dan panggilan sql kami disimpan dalam kontrol versi yang sama, tanpa "lupa" untuk menjalankan beberapa aplikasi eksternal untuk memperbarui.