Saya bekerja di sebuah proyek di salah satu dari 3 firma konsultasi IT terbaik di dunia, dan diberitahu oleh DBA bahwa prosedur yang tersimpan dalam praktik terbaik perusahaan bukanlah "praktik terbaik". Ini sangat bertentangan dengan semua yang saya pelajari.

Prosedur yang tersimpan memberi Anda penggunaan kembali kode, dan enkapsulasi (dua pilar pengembangan perangkat lunak), keamanan (Anda dapat memberikan / mencabut izin pada proc yang disimpan secara individu), melindungi Anda dari serangan injeksi SQL, dan juga membantu dengan kecepatan (meskipun itu DBA mengatakan bahwa dimulai dengan SQL Server 2008 yang bahkan query SQL reguler dikompilasi jika dijalankan cukup banyak).

Kami sedang mengembangkan aplikasi yang kompleks menggunakan metodologi pengembangan perangkat lunak Agile. Adakah yang bisa memikirkan alasan bagus mengapa mereka tidak ingin menggunakan procs yang disimpan? Dugaan saya adalah bahwa DBA tidak ingin mempertahankan procs yang disimpan, tetapi tampaknya ada terlalu banyak negatif untuk membenarkan keputusan desain seperti itu.

Dalam pengalaman saya bekerja pada proyek yang sangat besar, Anda harus sangat jelas di mana logika bisnis tinggal. Jika Anda mengizinkan lingkungan tempat pengembang individu dapat menempatkan logika bisnis di lapisan objek bisnis atau dalam prosedur tersimpan yang mereka inginkan, aplikasi besar menjadi SANGAT sulit untuk dipahami dan dipelihara.

Prosedur tersimpan sangat bagus untuk mempercepat operasi DB tertentu. Keputusan arsitektur saya adalah meninggalkan semua logika di lapisan bisnis aplikasi dan menggunakan prosedur tersimpan dengan cara yang ditargetkan untuk meningkatkan kinerja di mana pembandingan menunjukkan bahwa itu dibenarkan.

Beberapa Pengamatan

Prosedur tersimpan memberi Anda penggunaan kembali kode, dan enkapsulasi (dua pilar pengembangan perangkat lunak),

Hanya jika Anda menggunakannya dengan benar dalam konteks di mana seharusnya digunakan. Klaim yang sama dapat dikatakan tentang fungsi (dalam pemrograman terstruktur) atau metode (dalam pemrograman berorientasi objek), namun, kita melihat fungsi 1K dan objek mega-ass.

Artefak tidak memberi Anda manfaat itu. Penggunaan artefak yang tepat adalah yang memberikan manfaat tersebut.

keamanan (Anda dapat memberikan / mencabut izin pada masing-masing proc yang disimpan),

Iya. Ini adalah poin yang bagus dan salah satu alasan utama saya suka prosedur tersimpan. Mereka memberikan kontrol akses granularity yang lebih baik daripada apa yang biasanya dapat dicapai hanya dengan tampilan dan akun pengguna.

melindungi Anda dari serangan injeksi SQL,

Itu tidak spesifik untuk SPs karena Anda dapat mencapai tingkat perlindungan yang sama dengan pernyataan SQL berparameter dan scrubbing input. Saya akan menggunakan SP selain itu, sebagai masalah "keamanan mendalam" .

dan juga membantu dengan kecepatan (meskipun itu DBA mengatakan bahwa dimulai dengan SQL Server 2008 yang bahkan permintaan SQL reguler dikompilasi jika dijalankan cukup kali).

Ini sangat spesifik vendor database, tetapi secara umum DBA Anda benar. Pernyataan SQL (statis atau parametrik) dapat dikompilasi. SP membantu jika Anda ingin / perlu menggabungkan dan menghitung data yang tidak dapat Anda lakukan dengan pernyataan SQL sederhana, tetapi terintegrasi erat dengan SQL dan tidak menjamin perjalanan pulang pergi ke server aplikasi.

Contoh yang baik adalah meminta data ke kursor sementara (atau kursor) untuk menjalankan SQL itu sendiri. Anda dapat melakukannya secara terprogram di server aplikasi, atau Anda dapat menyimpan beberapa round-trip dengan melakukannya di db.

Namun, ini seharusnya tidak menjadi norma. Jika Anda memiliki banyak dari kasus-kasus itu, maka itu adalah tanda desain database yang buruk (atau Anda menarik data dari skema database yang tidak begitu kompatibel di seluruh departemen.)

Kami sedang mengembangkan aplikasi yang kompleks menggunakan metodologi pengembangan perangkat lunak Agile.

Agility berkaitan dengan proses rekayasa perangkat lunak dan manajemen persyaratan, dan bukan teknologi.

Adakah yang bisa memikirkan alasan bagus mengapa mereka tidak ingin menggunakan procs yang disimpan?

Pertanyaan yang salah

Pertanyaannya salah dan setara dengan menanyakan "apakah ada alasan bagus untuk tidak menggunakan GOTO"? Saya berpihak pada Niklaus Wirth lebih daripada dengan Dijkstra tentang hal ini. Saya bisa mengerti dari mana sentimen Dijkstra berasal, tapi saya tidak percaya itu 100% berlaku dalam semua kasus. Sama dengan procs toko dan teknologi apa pun.

Suatu alat baik ketika digunakan dengan baik untuk tujuan yang dimaksudkan, dan ketika itu adalah alat terbaik untuk tugas tertentu. Menggunakannya sebaliknya bukan indikasi bahwa alat itu salah, tetapi bahwa pengguna tidak tahu apa yang dia lakukan.

Pertanyaan yang tepat adalah "jenis pola penggunaan prosedur tersimpan apa yang harus dihindari." Atau, "dalam kondisi apa saya harus (atau tidak seharusnya) menggunakan prosedur tersimpan" . Mencari alasan untuk tidak menggunakan teknologi hanya menyalahkan alat sebagai lawan menempatkan tanggung jawab teknik tepat di tempatnya - di insinyur.

Dengan kata lain, itu adalah cop-out atau pernyataan ketidaktahuan.

Dugaan saya adalah bahwa DBA tidak ingin mempertahankan procs yang disimpan, tetapi tampaknya ada terlalu banyak negatif untuk membenarkan keputusan desain seperti itu.

Apa yang mereka lakukan kemudian adalah memproyeksikan hasil keputusan teknik buruk mereka pada alat yang mereka gunakan dengan buruk.

Apa yang harus dilakukan dalam kasus Anda?

Pengalaman saya adalah, ketika di Roma, lakukan seperti yang dilakukan orang Romawi .

Jangan melawannya. Jika orang-orang di perusahaan Anda ingin memberi label procs toko sebagai praktik yang buruk, biarkan mereka. Namun, maklum, ini bisa menjadi bendera merah dalam praktik rekayasa mereka.

Pelabelan umum hal-hal sebagai praktik buruk biasanya dilakukan dalam organisasi dengan banyak programmer yang tidak kompeten. Dengan memasukkan hal-hal tertentu ke daftar hitam, organisasi mencoba membatasi kerusakan yang diakibatkan oleh ketidakmampuan mereka sendiri secara internal. Aku tidak mencintaimu.

Generalisasi adalah induk dari semua gangguan. Mengatakan bahwa procs yang disimpan (atau jenis teknologi apa pun) adalah praktik yang buruk, itu generalisasi. Generalisasi adalah solusi untuk yang tidak kompeten. Insinyur tidak bekerja dengan generalisasi terang-terangan. Mereka melakukan analisis berdasarkan kasus per kasus, melakukan trade-off analisis dan melaksanakan keputusan dan solusi teknik sesuai dengan fakta yang ada, dalam konteks di mana mereka seharusnya menyelesaikan masalah.

Insinyur yang baik tidak menyebut hal-hal sebagai praktik buruk dengan cara generalisasi. Mereka melihat masalah, memilih alat yang sesuai, melakukan trade-off. Dengan kata lain, mereka melakukan rekayasa.

Pendapat saya tentang bagaimana tidak menggunakannya

• Jangan letakkan logika kompleks di luar pengumpulan data (dan mungkin beberapa transformasi) di dalamnya. Tidak apa-apa untuk memasukkan beberapa logika pemijatan data di dalamnya, atau untuk mengumpulkan hasil dari beberapa kueri dengannya. Tapi itu saja. Apa pun di luar itu akan memenuhi syarat sebagai logika bisnis yang harus berada di tempat lain.

• Jangan menggunakannya sebagai satu-satunya mekanisme pertahanan Anda terhadap injeksi SQL. Anda membiarkannya di sana seandainya terjadi sesuatu yang buruk pada mereka , tetapi harus ada banyak logika defensif di depan mereka - validasi / scrubbing sisi klien, validasi / scrubbing sisi server, mungkin transformasi menjadi tipe yang masuk akal pada Anda model domain, dan akhirnya diteruskan ke pernyataan parametrized (yang bisa parametrized statement SQL atau procs yang disimpan parametrized).

• Jangan membuat basis data satu-satunya tempat yang berisi procs toko Anda. Procs toko Anda harus diperlakukan sama seperti Anda memperlakukan kode sumber C # atau Java Anda. Yaitu, sumber mengontrol definisi tekstual procs toko Anda. Orang-orang mengatakan bahwa procs toko tidak dapat dikontrol sumber - bullcrap, mereka hanya tidak tahu apa yang mereka bicarakan.

Pendapat saya tentang bagaimana / di mana menggunakannya

• Aplikasi Anda membutuhkan data yang perlu diubah atau dikumpulkan dari beberapa kueri atau tampilan. Anda dapat melepasnya dari aplikasi ke db. Di sini Anda harus melakukan analisis kinerja karena a) mesin basis data lebih efisien daripada server aplikasi dalam melakukan hal-hal ini, tetapi b) server aplikasi (kadang-kadang) lebih mudah untuk menskala secara horizontal.

• Kontrol akses butiran halus. Anda tidak ingin beberapa orang bodoh yang menjalankan cartesian bergabung dalam db Anda, tetapi Anda tidak bisa hanya melarang orang untuk mengeksekusi pernyataan SQL yang sewenang-wenang begitu saja. Solusi khas adalah untuk memungkinkan pernyataan SQL sewenang-wenang dalam pengembangan dan lingkungan UAT, sementara melarang mereka dalam lingkungan systest dan produksi. Pernyataan apa pun yang harus dibuat untuk systest atau produksi masuk ke prosedur toko, kode ditinjau oleh pengembang dan dBA.

Segala kebutuhan yang sah untuk menjalankan pernyataan SQL yang tidak ada dalam proc store akan melewati nama pengguna / akun dan kumpulan koneksi yang berbeda (dengan penggunaan yang sangat dipantau dan tidak disarankan.)

• Dalam sistem seperti Oracle, Anda bisa mendapatkan akses ke LDAP, atau membuat symlink ke database eksternal (katakanlah memanggil proc toko di db mitra bisnis melalui vpn.) Cara mudah untuk melakukan kode spaghetti, tetapi itu berlaku untuk semua paradigma pemrograman, dan kadang-kadang Anda memiliki persyaratan bisnis / lingkungan spesifik yang merupakan satu-satunya solusi. Store procs membantu merangkum nastiness itu di satu tempat saja, dekat dengan data dan tanpa harus melintasi ke server aplikasi.

Apakah Anda menjalankan ini di db sebagai proc toko atau di server aplikasi Anda tergantung pada analisis trade-off yang harus Anda lakukan, sebagai insinyur. Kedua opsi harus dianalisis dan dibenarkan dengan beberapa jenis analisis. Pergi satu arah atau lain dengan hanya menuduh alternatif lain sebagai "praktik buruk", itu hanya rekayasa yang lumpuh.

• Dalam situasi di mana Anda tidak dapat meningkatkan server aplikasi Anda (mis. Tidak ada anggaran untuk perangkat keras atau cloud baru) tetapi dengan banyak kapasitas pada back-end db (ini lebih khas yang banyak orang akui untuk mengakuinya), ia membayar untuk memindahkan logika bisnis untuk menyimpan procs. Tidak cantik dan dapat menyebabkan model domain anemia ... tapi sekali lagi ... analisis trade-off, hal yang paling payah oleh peretas.

Apakah itu menjadi solusi permanen atau tidak, itu khusus untuk kendala yang diamati pada saat tertentu.

Semoga ini bisa membantu.

Alasannya adalah bahwa mengandalkan lapisan prosedur yang tersimpan membatasi portabilitas dan mengikat Anda ke DB tertentu. Biaya pemeliharaan tambahan juga disebut sebagai alasan. Saya juga ingin mengomentari poin yang Anda buat ini:

(prosedur tersimpan) melindungi Anda dari serangan injeksi SQL

Ini sebenarnya query parametrized yang melindungi Anda, yang dapat Anda lakukan dengan mudah dalam query teks biasa.

Beberapa alasan yang saya setujui procs yang disimpan bukan praktik terbaik.

• Logika bisnis dan aplikasi harus dalam kode bukan dalam database. Menempatkan logika dalam DB adalah mencampuradukkan keprihatinan.
• Anda tidak dapat menguji procs yang disimpan dengan mulus seperti kode dalam proyek unit test konvensional Anda dengan sisa logika aplikasi.
• Saya tidak menemukan procs yang disimpan sebagai kondusif untuk menguji pemrograman pertama ketika saya menulis kode.
• Procs yang disimpan tidak mudah untuk di-debug sebagai kode aplikasi ketika Anda sedang men-debug program Anda di IDE.
• Kontrol versi / Kontrol sumber SP vs kode normal

Prosedur tersimpan memberi Anda penggunaan kembali kode, dan enkapsulasi (dua pilar pengembangan perangkat lunak),

Ya, tetapi dengan biaya untuk dapat memenuhi tujuan desain tangkas lainnya. Mereka lebih sulit dipertahankan, untuk satu hal. Jika proyek yang saya ikuti adalah indikasi, Anda mungkin akan berakhir dengan beberapa SP yang tidak kompatibel yang pada dasarnya melakukan pekerjaan yang sama, tanpa manfaat.

melindungi Anda dari serangan injeksi SQL,

Tidak mereka tidak. Aku bahkan tidak bisa menebak dari mana ide ini berasal, seperti yang sering kudengar, dan itu tidak benar. Mungkin mengurangi jenis serangan injeksi SQL tertentu, tetapi jika Anda tidak menggunakan query parametrized di tempat pertama, itu tidak masalah. Saya masih bisa '; DROP TABEL Akun; -

dan juga membantu dengan kecepatan (meskipun itu DBA mengatakan bahwa dimulai dengan SQL Server 2008 yang bahkan permintaan SQL reguler dikompilasi jika dijalankan cukup kali).

Mereka juga biasanya dikompilasi ketika Anda menggunakan pernyataan parametrized (setidaknya dengan beberapa DB yang saya gunakan). Pada saat aplikasi Anda mulai mengeksekusi kueri (atau terutama ketika Anda menjalankan kueri disiapkan yang sama beberapa kali), setiap keuntungan kinerja yang menurut Anda dimiliki oleh SP Anda sepenuhnya dapat diperdebatkan.

Satu- satunya alasan untuk menggunakan prosedur tersimpan, IMHO, adalah ketika Anda harus membuat kueri yang rumit dan bertingkat yang menarik dari berbagai sumber yang disusun. SP seharusnya tidak mengandung logika keputusan tingkat rendah, dan mereka tidak boleh hanya merangkum pertanyaan sederhana. Tidak ada manfaat dan hanya banyak kekurangan.

Dengarkan DBA Anda. Dia tahu ada apa.

Ini adalah kalimat resmi ketika saya bekerja untuk salah satu dari Lima Besar beberapa tahun yang lalu. Alasannya adalah karena SP terikat dengan implementasi tertentu (PL / SQL vs T / SQL vs ...), mereka tidak perlu membatasi pilihan teknologi.

Setelah menjalani migrasi satu sistem besar dari T / SQL ke PL / SQL, saya bisa mengerti argumennya. Saya pikir itu sedikit canard - berapa banyak tempat yang benar-benar bergerak dari satu database ke yang lain dengan kemauan?

Ketiga perusahaan tempat saya bekerja menggunakan prosedur tersimpan untuk logika aplikasi mereka dengan SQL Server. Saya belum benar-benar melihat hal-hal sebaliknya. Tetapi bagi saya mereka adalah kekacauan besar. Biasanya tidak ada fasilitas penanganan kesalahan yang baik atau fasilitas penggunaan kembali kode dengan prosedur tersimpan.

Katakanlah Anda memiliki prosedur tersimpan yang mengembalikan dataset yang ingin Anda gunakan, bagaimana Anda bisa menggunakannya dalam prosedur tersimpan di masa mendatang? Mekanisme pada SQL Server untuk itu tidak terlalu bagus. EXEC INTO ... hanya berfungsi pada satu atau dua tingkat) dari bersarang (saya lupa sekarang). Atau Anda harus menentukan terlebih dahulu tabel kerja dan meminta prosesnya dikunci. Atau Anda perlu membuat pra-temp tabel dan memiliki prosedur mengisi itu. Tetapi bagaimana jika dua orang menyebut temp table sebagai hal yang sama dalam dua prosedur berbeda yang tidak pernah mereka rencanakan untuk digunakan secara bersamaan? Dalam bahasa pemrograman normal apa pun, Anda bisa mengembalikan array dari suatu fungsi atau menunjuk ke suatu objek / struktur global yang dibagikan di antara mereka (kecuali untuk bahasa fungsional di mana Anda akan mengembalikan struktur data sebagai ganti hanya mengubah struktur global ... )

Bagaimana dengan kode yang digunakan kembali? Jika Anda mulai membuat ekspresi umum ke UDF (atau lebih buruk lagi pertanyaan), Anda akan memperlambat kodenya. Anda tidak dapat memanggil prosedur tersimpan untuk melakukan perhitungan kolom (kecuali jika Anda menggunakan kursor, berikan nilai kolom satu per satu, dan kemudian perbarui tabel / dataset Anda entah bagaimana). Jadi pada dasarnya untuk mendapatkan kinerja terbaik, Anda perlu memotong / menempelkan ekspresi umum di semua tempat yang merupakan mimpi buruk pemeliharaan ... Dengan bahasa pemrograman Anda dapat membuat fungsi untuk menghasilkan SQL umum dan kemudian memanggilnya dari mana saja ketika membangun string SQL. Maka jika Anda perlu menyesuaikan formula Anda dapat membuat perubahan di satu tempat ...

Bagaimana dengan penanganan kesalahan? SQL Server memiliki banyak kesalahan yang segera menghentikan eksekusi prosedur yang tersimpan dan beberapa bahkan memaksa pemutusan. Sejak 2005 ada coba / tangkap tetapi masih ada sejumlah kesalahan yang tidak bisa ditangkap. Hal yang sama juga terjadi dengan duplikasi kode pada kode penanganan kesalahan dan Anda benar-benar tidak dapat melewatkan pengecualian dengan mudah atau menggembungkannya ke tingkat yang lebih tinggi semudah kebanyakan bahasa pemrograman .....

Juga hanya kecepatan. Banyak operasi pada dataset tidak berorientasi pada SET. Jika Anda mencoba melakukan hal-hal yang berorientasi baris, Anda akan menggunakan kursor, atau Anda akan menggunakan "kursor" (ketika pengembang sering menanyakan setiap baris satu per satu dan menyimpan konten ke dalam variabel @ seperti kursor. ..Bahkan ini seringkali lebih lambat dari kursor FORWARD_ONLY). Dengan SQL Server 2000 saya memiliki sesuatu yang berjalan selama 1 jam sebelum saya membunuhnya. Saya menulis ulang kode itu dalam Perl dan selesai dalam 20 menit. Ketika bahasa scripting yang 20-80x lebih lambat dari C merokok SQL dalam kinerja, Anda pasti tidak punya bisnis menulis operasi berorientasi baris dalam SQL.

Sekarang SQL Server memang memiliki integrasi CLR dan banyak masalah ini hilang jika Anda menggunakan prosedur tersimpan CLR. Tetapi banyak DBA tidak tahu bagaimana menulis .NET program atau mematikan CLR karena masalah keamanan dan tetap dengan Transact SQL .... Juga bahkan dengan CLR Anda masih memiliki masalah berbagi data antara beberapa prosedur dengan cara yang efisien .

Secara umum, hal yang paling sulit untuk diukur adalah database. Jika semua logika bisnis Anda ada di database, maka ketika database menjadi terlalu lambat Anda akan memiliki masalah. Jika Anda memiliki lapisan bisnis, Anda bisa menambahkan lebih banyak caching dan lebih banyak server bisnis untuk meningkatkan kinerja. Secara tradisional server lain untuk menginstal windows / linux dan menjalankan .NET / Java jauh lebih murah daripada membeli server database lain dan melisensikan lebih banyak SQL Server. SQL Server memang memiliki lebih banyak dukungan clustering sekarang, awalnya tidak benar-benar memilikinya. Jadi jika Anda memiliki banyak uang, Anda dapat menambahkan pengelompokan atau bahkan melakukan pengiriman log untuk membuat beberapa salinan read only. Tetapi secara keseluruhan ini akan jauh lebih mahal daripada hanya memiliki menulis di belakang cache atau sesuatu.

Lihat juga fasilitas Transact-SQL. Manipulasi String? Saya akan mengambil kelas Java String Class / Tokenizer / Scanner / Regex setiap hari. Hash Tables / Linked Linked / Etc. Saya akan mengambil kerangka Java Collection, dll ... Dan hal yang sama untuk .NET ... Baik C # dan Java adalah bahasa yang jauh lebih berkembang daripada Transact SQL ... Heck coding dengan Transact-SQL membuat saya iri dengan C .. .

Pada prosedur tersimpan ditambah lebih efisien untuk bekerja dengan dataset besar dan menerapkan beberapa pertanyaan / kriteria untuk mengecilkannya sebelum mengembalikannya ke lapisan bisnis. Jika Anda harus mengirim banyak kumpulan data besar ke aplikasi klien dan memecah data di klien itu akan jauh lebih tidak efisien daripada hanya melakukan semua pekerjaan di server.

Prosedur yang tersimpan juga baik untuk keamanan. Anda dapat memotong semua akses ke tabel yang mendasarinya dan hanya mengizinkan akses melalui prosedur yang tersimpan. Dengan beberapa teknik modern seperti XML, Anda dapat memiliki prosedur tersimpan yang melakukan pembaruan batch. Kemudian semua akses dikendalikan melalui prosedur yang tersimpan sehingga selama mereka aman / benar data dapat memiliki integritas lebih.

Argumen injeksi SQL tidak benar-benar berlaku lagi karena kami memiliki pertanyaan parameter di sisi bahasa pemrograman. Juga benar-benar bahkan sebelum permintaan parameterisasi sedikit ganti ("'", "' '") bekerja sebagian besar waktu juga (meskipun masih ada trik yang digunakan untuk melewati akhir string untuk mendapatkan apa yang Anda inginkan).

Secara keseluruhan saya pikir SQL dan Transact SQL adalah bahasa yang bagus untuk query / memperbarui data. Tetapi untuk pengkodean semua jenis logika, melakukan manipulasi string (atau manipulasi file heck .... Anda akan terkejut dengan apa yang dapat Anda lakukan dengan xp_cmdshell ....) tolong tidak. Saya berharap menemukan tempat di masa depan yang tidak menggunakan prosedur tersimpan kebanyakan. Dari sudut pandang pemeliharaan kode, itu adalah mimpi buruk. Juga apa yang terjadi jika Anda ingin berganti platform (walaupun benar-benar jika Anda membayar untuk Oracle / DB2 / Sybase / Sql Server / dll. Anda mungkin juga mendapatkan semua yang Anda bisa dari mereka dengan menggunakan setiap ekstensi kepemilikan Anda yang dapat membantu Anda keluar. ..)

Juga mengejutkan sering logika bisnis tidak sama. Di dunia ideal Anda akan menempatkan semua logika dalam prosedur tersimpan dan membagikannya di antara aplikasi. Tetapi cukup sering logika berbeda berdasarkan aplikasi dan prosedur tersimpan Anda akhirnya menjadi monolit yang terlalu rumit sehingga orang takut untuk berubah dan tidak memahami semua implikasi. Sedangkan dengan bahasa berorientasi objek yang baik Anda dapat mengkodekan lapisan akses data yang memiliki beberapa antarmuka / kait standar yang dapat ditimpa setiap aplikasi dengan kebutuhan mereka sendiri.

Bagaimana versi Anda menyimpan prosedur di server?

Jika Anda memindahkan prosedur yang tersimpan ke server dari kontrol versi, Anda mengeluarkan rencana eksekusi yang disimpan.

Prosedur tersimpan seharusnya tidak dapat dimodifikasi secara langsung di server, jika tidak, bagaimana Anda tahu apa yang sebenarnya sedang berjalan - sekarang? Jika tidak, alat penyebaran perlu akses untuk menulis prosedur tersimpan ke database. Anda harus menggunakan di setiap bangunan (rencana eksekutif mungkin harus berbeda)

Meskipun prosedur yang tersimpan adalah non-portabel, tidak ada SQL secara umum (pernah melihat penanganan tanggal oracle - uggghhh).

Jadi, jika Anda menginginkan portabilitas, buat API akses data internal. Anda dapat memanggil fungsi ini seperti panggilan, dan secara internal Anda dapat membangun dalam istilah apa pun yang Anda inginkan, dengan permintaan parameter, dan dapat dikontrol versi.

Ini sangat bertentangan dengan semua yang saya pelajari.

Anda mungkin perlu keluar lebih banyak. [Seringai] Serius, procs yang disimpan telah menurun setidaknya selama 10 tahun. Sudah cukup banyak sejak n-tier menggantikan client-server. Penurunan hanya dipercepat dengan adopsi bahasa OO seperti Java, C #, Python, dll.

Itu tidak berarti procs yang disimpan tidak memiliki pendukung dan pendukung mereka - tetapi ini adalah diskusi dan debat yang sudah berjalan lama. Ini bukan hal baru, dan kemungkinan masih akan berlangsung cukup lama; IMO, lawan dari procs yang disimpan jelas menang.

Prosedur tersimpan memberi Anda penggunaan kembali kode, dan enkapsulasi (dua pilar pengembangan perangkat lunak)

Sangat benar. Tapi, begitu juga dengan layer OO yang dirancang dengan baik.

keamanan (Anda dapat memberikan / mencabut izin pada masing-masing proc yang disimpan)

Meskipun Anda dapat melakukannya, sedikit yang melakukannya karena keterbatasan yang serius. Keamanan di tingkat DB tidak cukup granular untuk membuat keputusan yang sadar konteks. Karena kinerja dan overhead manajemen, tidak biasa memiliki koneksi per pengguna juga - jadi Anda masih memerlukan beberapa tingkat otorisasi dalam kode aplikasi Anda. Anda dapat menggunakan login berbasis peran, tetapi Anda harus membuatnya untuk peran baru, mempertahankan peran yang Anda jalankan, mengalihkan koneksi untuk melakukan pekerjaan "level sistem" seperti pencatatan, dll. Dan, pada akhirnya, jika aplikasi Anda dimiliki - begitu juga koneksi Anda ke DB.

melindungi Anda dari serangan injeksi SQL

Tidak lebih dari melakukan kueri parametrized. Yang perlu Anda lakukan pula.

dan juga membantu dengan kecepatan (meskipun itu DBA mengatakan bahwa dimulai dengan SQL Server 2008 yang bahkan permintaan SQL reguler dikompilasi jika dijalankan cukup kali).

Saya pikir itu dimulai pada MSSQL 7 atau 2000. Sudah ada banyak perdebatan, pengukuran, dan informasi yang salah pada kinerja proc yang disimpan vs inline SQL - Saya benjolkan semuanya di bawah YAGNI. Dan, jika Anda membutuhkannya, uji.

Kami sedang mengembangkan aplikasi yang kompleks menggunakan metodologi pengembangan perangkat lunak Agile. Adakah yang bisa memikirkan alasan bagus mengapa mereka tidak ingin menggunakan procs yang disimpan?

Saya tidak bisa memikirkan banyak alasan yang Anda inginkan . Java / C # / bahasa GL ke-3 semuanya jauh lebih mampu daripada T-SQL pada enkapsulasi, penggunaan kembali, dan keresahan, dll. Sebagian besar gratis diberikan ORM yang setengah layak.

Juga, diberi saran untuk "mendistribusikan sesuai kebutuhan, tetapi tidak lebih" - Saya pikir beban pembuktian hari ini adalah pada pendukung SP. Alasan umum untuk menyimpan proc berat adalah bahwa T-SQL lebih mudah daripada OO, dan toko memiliki pengembang T-SQL yang lebih baik daripada OO. Atau, bahwa DBA berhenti di lapisan basis data, dan procs yang disimpan adalah antarmuka antara dev dan DBA. Atau, Anda mengirim produk semi-kustom dan procs yang disimpan dapat disesuaikan pengguna. Tanpa beberapa pertimbangan seperti itu, saya pikir default untuk setiap proyek Agile SW hari ini adalah ORM.

Mempertimbangkan semua kasus di atas, saya ingin menambahkan satu lagi. Pilihan SP mungkin tergantung pada pilihan orang juga.

Saya pribadi merasa frustrasi ketika orang-orang menaruh logika yang sangat kompleks dalam SP dan saya percaya SP seperti itu sangat kompleks untuk dijaga dan di-debug. Bahkan banyak kasus pengembang sendiri menghadapi masalah ketika debugging dalam kode di belakang (katakanlah bagian bahasa) jauh lebih mudah daripada di SP.

SP seharusnya hanya digunakan untuk operasi sederhana. Nah itu pilihan saya.

Saya ingin membahas pro dan kontra dengan procs tersimpan. Kami menggunakannya secara luas dengan LedgerSMB , dan aturan kami adalah, dengan beberapa ekstensi yang sangat spesifik, "jika itu kueri, buat itu menjadi proc yang disimpan."

Alasan kami melakukan ini adalah untuk memfasilitasi penggunaan kembali lintas-bahasa. Tidak ada cara yang lebih baik untuk melakukan ini dengan jujur.

Pada akhirnya pertanyaannya selalu pada detail. Prosedur yang digunakan dengan baik dan disimpan membuat segalanya lebih mudah, dan penggunaannya yang buruk membuat hal-hal menjadi jauh lebih sulit.

Begitu seterusnya ke sisi con.

1. Seperti yang biasa digunakan, prosedur yang tersimpan rapuh. Digunakan sendiri, mereka menciptakan kemungkinan menambahkan bug ke kode Anda di tempat-tempat yang tidak Anda harapkan tanpa alasan lain selain itu sintaks panggilan berubah. Digunakan sendiri ini sedikit masalah. Ada terlalu banyak kohesi antar lapisan dan ini menyebabkan masalah.

2. Ya, adalah mungkin untuk mendapatkan injeksi sql intra-sproc jika melakukan sql dinamis apa pun. Adalah hal yang buruk untuk terlalu percaya diri di bidang ini, dan akibatnya seseorang perlu memiliki pengalaman yang signifikan dalam keamanan di bidang ini.

3. Perubahan pada antarmuka agak bermasalah dengan prosedur tersimpan karena alasan # 1 di atas tetapi ini bisa menjadi mimpi buruk yang sangat besar jika sejumlah besar aplikasi klien terlibat.

Di atas cukup sulit untuk disangkal. Mereka terjadi. Semua orang, pro-SP dan anti-SP mungkin memiliki cerita horor tentang ini. Masalahnya bukan tidak dapat dipecahkan tetapi jika Anda tidak memperhatikannya, Anda tidak dapat menyelesaikannya (di LedgerSMB kami menggunakan pencari lokasi layanan untuk secara dinamis membangun panggilan SP saat run-time, menghindari masalah di atas sepenuhnya. Sementara kami PostgreSQL hanya saja, hal serupa dapat dilakukan untuk db lain).

Ke positif. Dengan asumsi Anda dapat memecahkan masalah di atas, Anda mendapatkan:

1. Kemungkinan kejelasan yang ditingkatkan dalam operasi yang ditetapkan. Ini terutama benar jika permintaan Anda sangat besar atau sangat fleksibel. Ini juga mengarah pada peningkatan kemampuan uji.

2. Jika saya memiliki pencari lokasi yang sudah bekerja di area ini, saya menemukan prosedur tersimpan mempercepat proses pengembangan karena mereka membebaskan pengembang aplikasi dari masalah db dan sebaliknya. Ini memiliki beberapa kesulitan dalam melakukan yang benar tetapi tidak terlalu sulit untuk dilakukan.

3. Permintaan digunakan kembali.

Oh dan beberapa hal yang hampir tidak boleh Anda lakukan dalam SP:

1. logika non-transaksional. Anda mengirim email bahwa pesanan telah dikirim tetapi transaksi dibatalkan ... atau sekarang Anda sedang menunggu untuk melanjutkan server email untuk online .... atau lebih buruk Anda memutar kembali transaksi Anda hanya karena Anda tidak dapat mencapai server email ....

2. banyak pertanyaan kecil secara longgar dirangkai, ditaburi dengan logika prosedural ....

Kamu bekerja untuk siapa?

Jawabannya mungkin tergantung pada siapa Anda bekerja, perusahaan konsultan atau perusahaan itu sendiri. Apa yang terbaik untuk perusahaan sering kali tidak terbaik untuk perusahaan konsultan atau vendor perangkat lunak lain. misalnya Perusahaan yang cerdas ingin memiliki keunggulan permanen atas para pesaingnya. Sebaliknya, vendor perangkat lunak ingin dapat menggunakan solusi yang sama untuk semua bisnis di industri tertentu, dengan biaya terendah. Jika mereka berhasil dalam hal ini, tidak akan ada keunggulan kompetitif bersih untuk klien.

Dalam kasus khusus ini, aplikasi datang dan pergi tetapi sangat sering, database perusahaan hidup selamanya. Salah satu hal utama yang dilakukan RDBMS adalah mencegah data sampah masuk dari basis data. Ini dapat melibatkan prosedur tersimpan. Jika logikanya adalah logik yang baik dan sangat tidak mungkin berubah dari tahun ke tahun, mengapa itu tidak ada dalam database, menjaganya konsisten secara internal, terlepas dari aplikasi apa pun yang ditulis untuk menggunakan database? Bertahun-tahun kemudian seseorang akan memiliki pertanyaan yang mereka ingin tanyakan dari database dan itu akan dijawab jika sampah telah dicegah memasuki DB.

Jadi mungkin ini ada hubungannya dengan fakta bahwa DBA Anda bekerja untuk perusahaan konsultan. Semakin portabel mereka dapat membuat kode mereka, semakin banyak mereka dapat menggunakan kembali kode dari klien ke klien. Semakin banyak logika yang bisa mereka rekatkan dalam aplikasi mereka, semakin banyak perusahaan terikat pada vendor. Jika mereka meninggalkan kekacauan besar dalam proses, mereka akan dibayar untuk membersihkannya, atau tidak pernah melihat kekacauan itu lagi. Apa pun itu kemenangan bagi mereka.

Untuk lebih banyak diskusi di kedua sisi pagar, baca diskusi di coding horor . FWIW Saya condong ke pihak yang mendukung SP.

Sangat sulit untuk mengganti merek basis data dan menggunakan prosedur tersimpan yang sama.

Tim Anda juga tidak memiliki DBA dan tidak ada orang lain yang ingin terlibat dengan sql.

Ini tidak lebih dari kontes kencing programmer v DBA.

IMO itu tergantung. Prosedur tersimpan memiliki tempatnya, tetapi itu bukan praktik terbaik, juga bukan sesuatu yang harus dihindari dengan cara apa pun. Pengembang yang pintar tahu bagaimana cara mengevaluasi situasi tertentu dengan tepat dan menentukan apakah prosedur yang disimpan adalah jawabannya. Secara pribadi saya penggemar menggunakan semacam ORM (bahkan yang dasar seperti Linq mentah ke Sql) daripada prosedur yang tersimpan kecuali mungkin untuk laporan yang telah ditentukan atau serupa tapi sekali lagi itu benar-benar kasus per kasus.

Selalu menjadi sumber masalah untuk membuat logika bisnis terpecah di antara berbagai lapisan, menggunakan bahasa pemrograman yang berbeda. Melacak bug atau menerapkan perubahan jauh lebih sulit ketika Anda harus beralih antar dunia.

Yang mengatakan, saya tahu perusahaan yang melakukannya dengan cukup baik dengan meletakkan semua logika bisnis ke dalam paket PL / SQL yang tinggal di database. Itu bukan aplikasi yang sangat besar, tetapi juga tidak sepele; katakanlah 20K-100K LOC. (PL / SQL lebih cocok untuk sistem semacam itu daripada T-SQL, jadi jika Anda hanya tahu T-SQL, Anda mungkin geleng-geleng sekarang ...)

Ini adalah poin lain yang belum disebutkan:

Alat pembuatan kode dan alat rekayasa terbalik tidak dapat benar-benar mengatasi dengan baik prosedur tersimpan. Alat ini umumnya tidak dapat mengatakan apa yang dilakukan proc. Apakah proc mengembalikan hasil? Beberapa hasil? Apakah ia mengambil hasilnya dari beberapa tabel dan tabel sementara? Apakah proc hanya pernyataan pembaruan yang dienkapsulasi dan tidak mengembalikan apa pun? Apakah itu mengembalikan resultset, nilai kembali dan beberapa "output konsol"?

Jadi jika Anda ingin menggunakan alat untuk membuat data-transfer-objek DTO dan lapisan DAO secara otomatis (seperti "service builder" liferay melakukannya), Anda tidak dapat dengan mudah melakukannya.

Selain itu, ORM seperti Hibernate tidak dapat benar-benar berfungsi dengan baik ketika sumber data adalah SP. Akses data terbaik hanya untuk dibaca.

Pemrograman solo, saya tidak bisa menahan penulisan prosedur yang tersimpan.

Saya menggunakan MySQL terutama. Saya belum pernah menggunakan database berorientasi objek sebelumnya seperti PostGreSQL, tapi apa yang bisa saya lakukan dengan SP di MySQL adalah abstrak struktur tabel sedikit. SP memungkinkan saya untuk merancang tindakan primitif ini, yang input dan outputnya tidak akan berubah , bahkan jika database di bawahnya memang berubah.

Jadi, saya punya prosedur yang disebut logIn. Ketika Anda masuk, Anda selalu hanya lulus usernamedan password. Hasil yang dikembalikan adalah integer userId.

Ketika logInprosedur tersimpan, sekarang saya dapat menambahkan pekerjaan tambahan yang harus dilakukan saat login yang terjadi pada saat yang sama dengan login awal. Saya menemukan serangkaian pernyataan SQL dengan logika tertanam dalam prosedur tersimpan yang lebih mudah untuk ditulis daripada (memanggil lingkungan FETCH) -> (dapatkan hasil) -> (memanggil lingkungan FETCH) seri yang harus Anda lakukan ketika Anda menulis sisi server logika Anda.

Saya ingin juga menunjukkan bahwa prosedur tersimpan menggunakan waktu cpu di server. Tidak banyak, tetapi beberapa. Beberapa pekerjaan yang dilakukan dalam prosedur kerja dapat dilakukan di aplikasi. Lebih mudah untuk mengukur lapisan aplikasi daripada lapisan data.

Saya setuju dengan Mark bahwa komunitas telah benar-benar menjauh dari prosedur tersimpan untuk beberapa waktu sekarang. Sementara banyak poin yang disampaikan poster asli mengapa kita mungkin ingin menggunakan SPs adalah valid pada satu waktu, itu sudah cukup lama dan, seperti poster lain katakan, lingkungan telah berubah. Misalnya, saya ingat satu argumen UNTUK menggunakan SPs 'back in the day' adalah pencapaian kinerja yang dicapai karena rencana eksekusi mereka 'pra-dikompilasi' sementara SQL dinamis dari kode kami harus 'dikompilasi ulang' dengan setiap eksekusi. Ini tidak lagi menjadi masalah karena database utama telah berubah, diperbaiki, diadaptasi, dll.

Yang mengatakan, kami menggunakan SP pada proyek saya saat ini. Alasannya adalah hanya karena kami sedang membangun aplikasi baru di atas database yang ada yang masih mendukung aplikasi lama. Akibatnya, membuat perubahan skema sangat sulit hingga kami mematikan aplikasi lawas. Kami membuat keputusan sadar untuk merancang aplikasi baru kami berdasarkan perilaku dan aturan yang diperlukan untuk aplikasi tersebut dan menggunakan SPs untuk sementara waktu berinteraksi dengan database seperti yang kami inginkan dan memungkinkan SPs untuk beradaptasi dengan SQL yang ada . Ini berlaku untuk poin poster sebelumnya bahwa SPs memudahkan untuk membuat perubahan pada tingkat basis data tanpa memerlukan perubahan pada kode aplikasi. Menggunakan SPs sebagai implementasi dari pola Adaptor tentu masuk akal bagi saya (terutama mengingat proyek saya saat ini),

Fwiw, kami bermaksud menghapus SP ketika skema diperbarui. Tetapi, seperti semua hal lain dalam pengembangan perusahaan, kita akan melihat apakah itu pernah terjadi! [menyeringai]

Saya hanya ingin membuat ikhtisar singkat tentang bagaimana saya akan merekomendasikan menggunakan prosedur yang tersimpan. Saya tidak berpikir mereka adalah praktik yang buruk sama sekali, dan seperti orang lain katakan mereka harus digunakan dalam situasi yang tepat.

Saya dapat melihat masalah di mana prosedur penulisan untuk aplikasi yang berbeda dapat menjadi membingungkan dalam fungsi dan memisahkan logika bisnis dari aplikasi dan mengakibatkan database menjadi lebih tidak terorganisir dan membatasi juga.

Oleh karena itu, saya akan menggunakan prosedur tersimpan dalam tugas berorientasi data relasional khusus untuk database. Dengan kata lain, jika ada logika yang digunakan untuk operasi database yang konsisten dengan data untuk aplikasi apa pun, prosedur tersimpan dapat digunakan untuk menjaga data disimpan secara konsisten (masuk akal). Saya pikir contoh yang baik dari ini adalah: penebangan yang konsisten, pemeliharaan yang konsisten, bekerja dengan informasi sensitif, dll.

Tugas-tugas lain memanipulasi data agar sesuai dengan kebutuhan aplikasi yang mengikuti model data yang kuat dari database, saya pikir, kemudian harus disimpan di lapisan lain yang berisi logika bisnis. Singkatnya, manipulasi data spesifik database untuk konsistensi dapat menggunakan prosedur tersimpan, di mana konsistensi meluas melewati model skema integritas database.

Prosedur tersimpan "untuk saya" cocok untuk operasi "baca-saja" OLAP, jarang digunakan.

Untuk aturan bisnis, operasi baca / tulis OLTP saya lebih suka server aplikasi Java. Untuk memudahkan pengkodean dan sebanyak mungkin membebaskan cpu dan memori dari server master db. Dalam pengaturan ini semua kode dalam server aplikasi tidak sulit untuk ditinjau atau dicatat dan dapat diukur.

Yang penting bagi saya adalah lebih mudah untuk debug di lapisan bisnis daripada debug prosedur tersimpan.

Selain mendistribusikan logika bisnis secara tidak perlu, dan mengikat Anda ke vendor database tertentu, saya juga sangat yakin menggunakan teknologi untuk apa yang dimaksudkan. Database hanya itu, penyimpanan data relasional. Gunakan untuk menyimpan data, tidak ada yang lain.

Pilih alat Anda dengan bijak dan Anda akan menyelamatkan diri Anda dari dunia yang terluka dalam jangka panjang.