Stored Procedures, praktik buruk di salah satu perusahaan konsultan perangkat lunak TI terbesar di dunia?


148

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.


3
Penggunaan kembali kode apa yang ditambahkannya? Bagaimana jika klien Anda menggunakan database yang berbeda. Harus membuang semua SP dan mulai dari awal. Jangan lindungi Anda dari injeksi sql. Kecepatan minimal dalam kebanyakan kasus.
Rig

32
Ingatlah bahwa sebagian besar perusahaan konsultan TI besar memiliki motif untuk memaksimalkan jam yang dapat ditagih sambil menjaga pantat mereka tetap tertutup. Orang-orang tua dengan pengaruh apa pun di perusahaan-perusahaan ini juga cenderung menjadi pemain dan birokrat daripada teknisi. Saya akan mengambil hal-hal seperti itu dari sebuah perusahaan konsultan dengan sebutir garam - Saya mendapatkan lebih dari satu perusahaan konsultan dari omong kosong dengan memperbaiki praktik 'terbaik' mereka.
ConcernedOfTunbridgeWells

1
@Rig Code reuse ditambahkan sama seperti untuk fungsi bahasa apa pun - dengan membungkus kode dalam wadah yang dapat digunakan kembali. Prosedur yang tersimpan tentu saja melindungi Anda dari injeksi SQL selama Anda tidak mengeksekusi string yang Anda buat. Mengatakan kecepatan minimal sepertinya tidak berpendidikan. Kebanyakan kasus tidak termasuk dalam kategori yang sama pada manfaat kinerja tetapi menunjukkan perbedaan yang luas.
Garet Claborn

1
@ GaretClaborn Tapi itu jauh lebih mungkin untuk arsitek lapisan aplikasi daripada tahun dan tahun data database historis. Pada aplikasi aplikasi apa pun yang tidak sepele. Dan jika Anda melakukannya, Anda akan menghabiskan berbulan-bulan porting kode kaya prosedur tersimpan. Ada sedikit manfaat untuk menambahkan satu lagi ketergantungan pada proyek Anda kecuali dalam situasi edgecase. Mereka memang ada tetapi sebagian besar waktu itu hanya menambah satu lagi rintangan untuk kelincahan proyek dan penggunaan kembali kode.
Rig

2
Berasal dari latar belakang di mana kami menggunakan sps hampir secara eksklusif, saya dapat memberi tahu Anda manfaat dari beralih dari mereka dan menggunakan ORM like Entity Framework. Terlalu banyak logika bisnis terbungkus dalam prosedur. Meskipun Anda dapat versi procs dengan beberapa alat kerja dan atau alat pihak ketiga. Ini tidak semudah melakukannya dalam kerangka seperti TFS atau GIT. Kode basis data Anda yang dipancarkan adalah agnostik dari penyedia RDBMS Anda. Jadi Anda dapat mengganti penyedia RDBMS di kemudian hari dengan sedikit sakit kepala.
ewahner

Jawaban:


280

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.


37
Saya tidak melihat hal-hal sesederhana itu. Bagi saya, itu SEMUA logika bisnis. Basis data, dengan atau tanpa prosedur tersimpan, menyediakan layanan tertentu dan memberikan jaminan tertentu. Idealnya, tidak mungkin kode aplikasi yang salah membuat database menjadi tidak konsisten. Jika prosedur tersimpan diperlukan untuk mempertahankan konsistensi itu, saya menggunakannya.
kevin cline

12
@kevin cline: Tentukan "keadaan tidak konsisten". Saya setuju bahwa fitur DB seperti integritas referensial berharga dan sangat mengurangi prospek kesalahan aplikasi yang menyebabkan kerusakan serius. Namun, secara umum, definisi "data konsisten" tergantung pada pelaksanaan aturan bisnis yang benar.
Eric J.

16
tambahkan juta saya ke Mayo juta. Logika bisnis terdistribusi membawa Anda keluar dari jalan raya praktik yang baik, langsung ke jalur kegilaan
Nico

27
+1 Logika bisnis merembes ke DAL adalah masalah besar saat menggunakan prosedur yang tersimpan.
Sistem Mati

30
@ChristopherMahan, saya TIDAK PERNAH ingin menggunakan database yang Anda desain. Itu adalah praktik terburuk yang mungkin dari perspektif basis data. Basis data sering terpengaruh secara langsung pada basis data. Adalah pandangan pendek untuk berpikir seseorang akan menggunakan lapisan bisnis untuk memperbarui sejuta catatan atau hal-hal lain yang terjadi seiring waktu. Impor tidak melalui lapisan bisnis (ya, saya ingin memproses 21 juta catatan impor saya satu per satu di lapisan bisnis). Penipuan jauh lebih mudah ketika Anda tidak memiliki kendala di tingkat basis data. Data buruk hampir 100% pasti.
HLGEM

163

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.


14
Ini jawaban yang sangat bagus.
yfeldblum

5
Jawaban yang bagus, tetapi apakah ini dimaksudkan untuk menjadi ironis? "Generalisasi adalah induk dari semua kekacauan."
bedwyr

2
Ya dan tidak. Komentar saya itu dimaksudkan untuk kalimat khusus yang dirujuk oleh OP dalam pertanyaan aslinya ( prosedur tersimpan bukan "praktik terbaik" .) Deskripsi kasar tentang prosedur penyimpanan sebagai praktik terbaik atau buruk adalah generalisasi. Mengabaikan konteks di mana mereka bisa baik atau buruk bisa (dan sering akan menyebabkan) untuk sekrup up ketika architecting atau merancang solusi;)
luis.espinal

7
+1 untuk "Pelabelan umum hal-hal sebagai praktik buruk biasanya dilakukan dalam organisasi dengan banyak programmer yang tidak kompeten." - pernah ke sana, menjalani itu, termasuk diberitahu kepada saya oleh manajer dev bahwa dia pikir saya punya solusi bagus untuk satu masalah rumit, tetapi jika dia terlihat mengizinkan saya untuk mengimplementasikannya maka itu akan membuka pintu air untuk Muppets.
Julia Hayward

1
@Shane Kamu benar. Namun saya percaya apa yang coba disampaikan oleh jawaban ini adalah kecenderungan beberapa kelompok insinyur untuk memaafkan kurangnya pengetahuan atau analisis mereka dengan memanggil kartu praktik buruk. Jawabannya bisa melihat beberapa perbaikan bagi kita yang kurang berpengalaman.
Cesar Hernandez

56

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.


18
Dan jika proc yang Anda simpan menggunakan semua jenis sql dinamis bersama dengan parameter string, Anda segera kembali ke tempat Anda memulai.
JeffO

4
Perbedaannya adalah bahwa izin akses dapat diatur untuk prosedur yang tersimpan berdasarkan prosedur, untuk query SQL yang diparameterisasi, Anda harus bergantung pada kewarasan programmer untuk tidak melakukannya + "blablabla"karena Anda harus mengizinkan SQL biasa, dan di situlah kontrol berakhir.
Coder

19
Saya tidak pernah mengerti argumen "mengikat Anda pada DB tertentu". Seberapa sering Anda mengambil program Anda dan memigrasikannya ke database yang sama sekali berbeda?
Mason Wheeler

11
@MasonWheeler - +1 setiap saat. Dalam setiap proyek yang cukup besar, aplikasi Anda akhirnya ditulis terhadap kelemahan produk DB yang diberikan. Mengubah ke DB lain menjadi pekerjaan utama tidak peduli apa karena DB baru akan memiliki keanehan yang berbeda!
Michael Kohne

6
@HLGEM - tetapi di dunia COTS, banyak DB diharapkan pada awalnya (sebenarnya, Anda memilih DB yang kompatibel). Bukan karena Anda melakukan port, melainkan Anda mendukung back-end yang berbeda, yang merupakan binatang yang sama sekali berbeda dari melakukan port.
Michael Kohne

46

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

7
Anda dapat dengan mudah melakukan pemrograman tes pertama pada prosedur tersimpan.

5
Hmmm, yah ... 1) Penggunaan prosedur tersimpan db tidak selalu menyiratkan bahwa logika bisnis dimasukkan ke dalamnya. 2) procs yang disimpan adalah beberapa hal yang paling mudah untuk unit test. 3) procs toko tidak selalu konduktif dari praktik uji pertama, benar, tetapi tidak semua yang dapat dihitung dapat diuji terlebih dahulu. 4) debugging seharusnya tidak menjadi masalah karena procs toko harus berisi tidak lebih dari pernyataan SQL dan kursor yang mudah diverifikasi. Juga, debugging harus dilakukan dengan terlebih dahulu menguji dan men-debug pernyataan SQL dalam kode, dan kemudian pindah ke procs toko ... hanya IMO btw.
luis.espinal

6
Kamu jelas bukan DB dev. Kontrol sumber, IDE - sangat mudah untuk men-debug SP jika Anda menggunakan TOAD atau IDE serupa, sama dengan versi.
gbjbaanb

6
2) pada pengujian unit procs yang disimpan. idk tentang kerangka kerja unit test lain tetapi setidaknya dengan MS Test (VisualStudio.TestTools.UnitTesting), menjalankan salah satu metode Assert pada proc yang disimpan setidaknya memerlukan koneksi Db, yang menurut definisi membuatnya lebih sebagai tes integrasi daripada unit uji. Dan proc yang disimpan dapat merujuk status tentang basis data pada tingkat basis data global. Ini mungkin tidak dapat dipalsukan atau memiliki antarmuka.
T. Webster

3
+1 Selain itu, bahasa prosedur tersimpan (pl / sql, t-sql, plpgsql, dll) sangat kikuk dan verbose. Jauh lebih mudah bagi saya untuk menggunakan bahasa skrip untuk membuat koneksi basis data dan menangani logika bisnis di luar basis data.

22

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.


1
Red Gate memiliki produk SQL Source Control untuk SQL Server, tapi saya setuju, mendorong logika ke procs yang disimpan adalah cara terbaik untuk memastikan bahwa Anda memiliki logika penting bukan di bawah kontrol versi apa pun.
Carson63000

17
@greyfade - "Saya belum melihat kontrol sumber untuk SP" - apakah Anda bercanda? Proc toko hanyalah file teks berdarah yang Anda unggah di mesin basis data Anda (yang mengambilnya, mengkompilasinya dan menginstalnya untuk eksekusi.) Setiap tempat saya pernah bekerja yang menyimpan procs, kami menyimpan kode sumber proc toko di, katakanlah, CVS, clearcase atau SCM mana pun yang digunakan. Mengatakan bahwa procs toko tidak dapat dikontrol oleh sumber (karena mereka ada di db) seperti mengatakan kode sumber aplikasi saya (Java, C # atau apa pun) tidak dapat dikontrol sumber karena dikompilasi dan digunakan dalam produksi.
luis.espinal

2
@ luis.espinal: Saya tidak mengatakan mereka tidak bisa mengendalikan sumber. Saya hanya mengatakan bahwa saya tidak tahu alat khusus untuk mempertahankan sejarah SP, menyiratkan mempertahankan sejarah itu dalam database. Tolong jangan marah-marah kepada saya hanya karena Anda salah membaca sesuatu.
greyfade

1
Semua procs yang tersimpan opur berada di bawah sumber conrtrol, hanya karena Anda telah melihat parctices buruk di masa lalu tidak berarti bahwa mereka melekat dalam menggunakan procs yang disimpan.
HLGEM

1
@ luis.espinal apakah tipikal sumber dari prosedur tersimpan dapat diambil kemudian dari database? Jika demikian, Anda bisa memiliki alat yang menariknya secara teratur, dan memiliki alat lain di tempat untuk membuat ulang instalasi dari awal. Lakukan sesekali untuk memastikannya akurat.

17

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?


10
@ DaveE: Untuk solusi perusahaan Anda mungkin benar. Jika Anda membuat perangkat lunak yang dikemas, segera setelah Anda mengirim MSSQL, prospek terbesar Anda akan menginginkannya berjalan di Oracle.
Eric J.

3
@ Eric: terlalu benar. Di tempat saya sekarang, kami menggunakan banyak SP dan memberi tahu orang-orang 'tidak' jika mereka tidak menginginkan MSSQL. Senang bisa melakukan itu.
DaveE

3
@DaveE: Apakah tim penjualan berharap Anda bisa mengatakan "ya"?
Eric J.

2
Ini tidak sebanyak memindahkan satu sistem dari satu basis data ke basis data yang lain, tetapi memiliki satu sistem untuk dapat menggunakan sistem basis data apa pun yang sudah dimiliki pelanggan. Database besar itu mahal.

@ EricJ: ya, tapi begitu mereka melihat apa yang harus dilakukan untuk komisi mereka, permintaan itu agak hilang.
DaveE

17

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.


6
Saya tidak bisa tidak menawarkan makanan untuk dipikirkan mengenai seluruh masalah yang berorientasi pada set prosedur. Saya telah melihat kursor basis data yang digunakan dalam semua jenis kasus di mana pendekatan itu hanya gila. Saya secara pribadi telah menggantikan SQL berbasis kursor eksplisit (Oracle PL / SQL, dalam kasus tertentu) dengan permintaan yang berorientasi pada set dan melihat hasilnya kembali dalam hitungan detik, bukannya 8 menit. Butuh waktu 30 menit untuk membedah kode kursor 1.000 baris itu dan "mendapatkannya". Query SQL yang dihasilkan singkat, elegan, sederhana. Orang terlalu sering meremehkan kekuatan server database mereka, dan terlalu cepat.
Craig

12

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.


6
Bagaimana versi Anda menyimpan prosedur di server? - Versi Anda mengontrol kode sumber proc toko. Ketika tiba saatnya untuk menyebarkan, Anda mengambil procs toko (dari baseline yang diberikan) dan Anda (atau dba Anda) menyebarkan ke produksi. Penugasan kembali (baik itu pada pengujian atau produksi) tentu saja menghancurkan rencana eksekutif yang tersimpan, tetapi itu akan terjadi secara independen apakah Anda sumber mengontrol SP Anda atau tidak.
luis.espinal

1
@BarryBrown Tidak berfungsi jika orang memiliki akses ke server secara langsung dan dapat mengubah prosedur yang tersimpan. Saya harus memiliki proses yang mengawasi SP, atau memiliki cek sebelum digunakan ...
Christopher Mahan

2
Jika Anda memiliki orang yang hanya mengubah sprocs mau tak mau pada server tanpa melakukan perubahan mereka untuk kontrol sumber, Anda memiliki masalah proses yang hampir pasti mempengaruhi pengembangan kode penting Anda, juga, bahkan jika Anda tidak menyadari itu.
Craig

1
Salah satu hal yang telah saya lakukan di masa lalu adalah menempatkan contoh pengembangan dari server database pada workstation masing-masing pengembang, atau jika itu tidak mungkin, maka setidaknya memiliki contoh "dev" dan "production" dari database. , dan semua skrip DDL dan DML, serta sampel data dan skrip memuat tinggal di bawah direktori mereka sendiri di pohon sumber, dan database secara rutin dibangun dari skrip-skrip tersebut menggunakan file MAKE. Pengembang juga dapat menggunakan nmake untuk membangun procs yang tersimpan tunggal. Jika mereka tidak meletakkannya di bawah kendali sumber, itu akan hilang pada mereka, dan mereka tahu itu.
Craig

1
... Saya tidak bermaksud terdengar meremehkan dalam komentar saya sebelumnya, dengan frasa "..., bahkan jika Anda tidak sadar ...". Yang ingin saya sampaikan adalah bahwa jika hal semacam itu terjadi dengan prosedur tersimpan, itu mungkin terjadi di bagian lain dari proyek, juga. Saya pribadi agak tidak suka kontrol sumber terintegrasi dalam IDE, sebagian karena saya pikir itu membuat orang agak malas dalam hal berpikir tentang apa sebenarnya artinya bagi tim dan proyek secara keseluruhan untuk membuat perubahan dan melakukan perubahan-perubahan itu ke kontrol sumber gudang. Hal-hal itu tidak boleh "otomatis" menurut saya.
Craig

9

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.


1
Ada BANYAK untuk mendapatkan kinerja jika Anda tidak harus mentransfer dataset raksasa dari database untuk melakukan hal-hal sederhana. Ukur, dan optimalkan jika perlu.

Tepat. Prosedur yang disimpan dapat digunakan seperti pisau bedah. Ini merupakan jaminan mutlak bahwa I / O di dalam server database memiliki bandwidth lebih banyak daripada I / O antara server database dan tingkat menengah Anda. Dan Anda tidak akan menulis lebih cepat, data yang lebih efisien, bergabung dengan kode di tingkat menengah Anda daripada mesin database yang ditulis di server database. Jika Anda mentransfer 1.000.000 baris data ke tingkat menengah untuk bergabung, yang tentu saja saya lihat, Anda hanya perlu dicambuk ... Seperti orang-orang yang mengatakan Anda harus "menulis kode rollback Anda sendiri." Penyakit jiwa.
Craig

1
Jangan meremehkan server basis data Anda. Pelajari cara menggunakannya dengan benar.
Craig

1
FWIW, Anda tidak perlu proc tersimpan untuk melakukan join di sisi basis data. Dan jika Anda menggunakan kursor untuk logika prosedural, kemungkinan Anda sudah kehilangan perang kinerja. Menyerahkan prosedur yang tersimpan tentu tidak sama dengan menyerah pada SQL atau menetapkan solusi berbasis.
Mark Brackett

1
Sepenuhnya benar, dan saya benar-benar berdebat mendukung SQL lebih dari berdebat khusus untuk sprocs. Tetapi kemudian memiliki SQL yang tertanam dalam kode imperatif Anda belum tentu merupakan kunci menuju kebahagiaan, bukan? Yang sering mengarah ke seluruh perdebatan ORM, yang kemudian mengarah pada saya menunjuk ke perbandingan kinerja antara akses db ORM-driven vs hanya belajar bagaimana menggunakan SQL. Saya telah melihat dan mendengar tentang sistem di mana, katakanlah, konsultan Oracle merekomendasikan untuk menjaga semua kemungkinan beban dari server database, yang mengarah ke middleware berat (dan sangat mahal!) Dengan kinerja luar biasa.
Craig

4

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.


4

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 ....


Setuju kuat, ulang: menjaga sampah non-transaksional dari prosedur tersimpan. Dalam contoh Email itu, pesan Email harus dimasukkan ke dalam antrian dan diservis secara asinkron. Bicara tentang menyiapkan diri Anda untuk kinerja yang hebat dan perilaku funky yang kurang, membuat transaksi basis data Anda bergantung pada respons server surat Anda? Astaga!
Craig

3

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.

masukkan deskripsi gambar di sini

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


1
Jawaban ini berfokus pada mengikat pertanyaan apakah menggunakan prosedur tersimpan atau tidak dengan pertanyaan tentang siapa Anda bekerja dan apa motivasi mereka. Turunkan suara. Jawabannya seharusnya berfokus pada mengikat pertanyaan apakah menggunakan prosedur tersimpan pro dan kontra dari prosedur tersimpan. Jika jawabannya terfokus pada gagasan bahwa SP menjaga sampah dari memasuki database, saya tidak akan downvoted. Saya tidak setuju, demi kepentingan pengungkapan, tetapi saya tidak akan kalah pendapat.
yfeldblum

Anda juga menautkan sebuah artikel dari tahun 2004, IMHO lanskap telah berubah sedikit sejak itu. ATAU / M telah menjadi jauh lebih biasa. Ruby / Rails ActiveRecord, MS keluar dengan linq & EF, Django untuk python, dll.
Brook

@Justice, dia benar, apakah praktik terbaik area tersimpan bergantung pada banyak pada siapa perusahaan itu dan apa peran yang mereka mainkan. Misalnya, procs yang disimpan memungkinkan Anda untuk mengatur izin pada proc itu sendiri dan tidak langsung di atas meja. Jika Anda melakukan pekerjaan keuangan apa pun dan harus mempertimbangkan kontrol internal, itu adalah satu-satunya pilihan yang layak untuk melindungi data Anda dari pengguna. Tetapi jika Anda membuat produk COTS dengan beberapa kemungkinan backend, mereka terlalu spesifik basis data. Jika Anda adalah perusahaan konsultan, Anda mungkin perlu mempertimbangkan beberapa pendekatan berbeda sebagai yang terbaik untuk keadaan tersebut.
HLGEM

3
@HLGEM Saya tidak keberatan dengan poin yang Anda kemukakan . Tapi saya keberatan dengan tesis jawaban bahwa alasan utama DBA mungkin memasukkan logika ke dalam aplikasi adalah karena dia adalah seorang konsultan dan bermaksud untuk mengacaukan pelanggan. Itu mengikat moral seseorang untuk memilih apakah akan menggunakan prosedur yang tersimpan. Menurut pendapat saya, ada argumen teknis di kedua sisi, dan argumen di kedua sisi akan berbeda dari aplikasi ke aplikasi, teknologi ke teknologi, perusahaan ke perusahaan, industri ke industri. Dan pertama-tama saya akan mencari pahala sebelum mengganggu motif.
yfeldblum

Dia bilang dia bekerja di perusahaan konsultan. Mempertahankan kontrol lebih besar atas kode vs prosedur tersimpan yang digunakan untuk situs pelanggan adalah alasan yang sangat sah bahwa ini mungkin merupakan "praktik terbaik" mereka. Mungkin bukan untuk "mengacaukan pelanggan" tetapi mungkin menjadi masalah kontrol yang lebih besar.
Jesse

3

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.


2

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.


Para downvoters akan berkomentar.
SandRock

2

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 ...)


2

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.


Sangat menarik bahwa alat penghasil kode tampaknya memiliki waktu yang sulit untuk mencari tahu apakah prosedur yang tersimpan mengembalikan hasil yang ditetapkan, ketika prosedur yang disimpan itu sendiri tidak memiliki masalah dengan itu.
Craig

2

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.


1

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.


3
Sulit untuk skala database?
JeffO

1
Setidaknya secara signifikan lebih mahal (kecuali Anda di MySQL) dan di banyak tempat saya telah bekerja mendapatkan lisensi SQL Server Enterprise Edition seperti menarik gigi
ben f.

penskalaan basis data tidak lebih sulit dari penskalaan akhir lapisan aplikasi
Brian Ogden

1

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]


0

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.


-1

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.


Anda membuat beberapa asumsi: bahwa OP memiliki kebutuhan untuk OLAP (tidak disebutkan dalam pertanyaan); bahwa platform yang digunakan memiliki server aplikasi Java (tidak mungkin karena tag adalah tentang SQL Server). Jawaban Anda juga tidak membawa apa pun yang belum dicakup oleh 22 jawaban lainnya
Adam Zuckerman

Saya hanya mengatakan jika saya memulai proyek baru, akan menggunakan prosedur tersimpan jarang untuk operasi read-only hanya pilihan pribadi. Saya merasa lebih nyaman untuk melakukan sebagian besar pengkodean pada lapisan logika bisnis daripada lapisan data.
jaizon lubaton

ini tampaknya tidak menawarkan sesuatu yang substansial atas poin yang dibuat dan dijelaskan dalam 24 jawaban sebelumnya, hampir tidak ada konten yang layak menabrak pertanyaan berusia 4 tahun
agas

-2

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.


jika Anda akan melakukan downvote maka lakukan itu, tetapi setidaknya jelaskan alasannya.
Nico

mungkin karena kamu salah. Sebuah SP tidak berarti Anda sedang menulis kode di sana, hanya menulis kueri akses data Anda (dalam 99% kasus saya pikir). Selain itu, hanya menempatkan pemicu dan batasan pada model data dianggap sebagai 'kode' - yaitu logika operasional, bukan data. Maka dari itu maksud saya bahwa Anda salah.
gbjbaanb

Di mana Anda mengatur transformasi pada data Anda yang tersimpan selain dalam database?
Chris Travers
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.