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.