Stored Procedure (Saklı Yordam – ben kısaca Sp olarak anacağım), iliÅŸkisel veritabanı sistemlerinde doÄŸrudan veritabanı üzerinde programlama yapmanızı saÄŸlayan yordamlardır. Büyük ya da küçük birçok veritabanı projesinde sıklıkla kullanılırlar. Ama benim uzun zamandır gözlemlediÄŸim birÅŸey, geliÅŸtiriciler arasında Sp kullanımıyla ilgili bir fikir ayrılığı var. Bir kısım olabildiÄŸince Sp kullanılmamasından yana diÄŸer kısım ise tam tersi. Bende bu yazıda konu hakkındaki fikirlerimi yansıtmaya çalışacağım.
Sp’ler birçok alanda bize oldukça yardımcı olabilirler. Özellikle hız açısından getirileri çok fazladır. Fakat bazı iÅŸlemler (örneÄŸin cursor çalıştırma gibi) ciddi performans sorunları doÄŸurabilir. Bunları dikkate alarak en sonda söyleyeceÄŸim ÅŸeyi baÅŸta söylemek istiyorum; Ben kesinlikle Sp kullanmak taraftarıyım ama nasıl?
Business Logic (Ä°ÅŸ Mantığı) iÅŸlemlerinizi olabilidiÄŸince Sp’lerde yapmaktan kaçının. Neden?
- Bir kere bu nesneye yönelimli programlama yaklaşımına terstir.
- Kod karışıklığı getirir (çoÄŸu iÅŸlemi Sp’lerde yapmak daha zordur).
- Kodların sonradan düzenlenmesi ve geliştirilmesi zorlaşır.
- Genelde Pl/Sql ve T-Sql gibi dillerde optimize edilmiÅŸ kod yazmak ve elde edilen resultset’leri iÅŸlemek zor olduÄŸundan sanılanın aksine ciddi performans sorunları doÄŸurabilir.Â
- Kullanıdığınız veritabanı sistemine bağlılık yaratacağından veritabanı bağımsızlığını baltalar (ki bu günümüz şartlarında hiç iyi birşey değil)
- Raporlama işlemlerinde kullanılabilirler. Özellikle Reporting Services gibi veritabanı sistemine bağlı bir raporlama aracı kullanılıyorsa çok daha iyi olur.
- Batch(çoklu) sorgularda kullanmak akıl karıdır.
- IF EXISTS gibi bazı istisnalar çok faydalıdır.
- ANSI Sql sorgularınızı (örn: insert, update, delete gibi) Sp’lerde tutmak çok mantıklıdır. Bu sayede bu sorgular tek bir yerde tutulmuÅŸ olur ve üzerinde deÄŸiÅŸiklik ve ekleme iÅŸleri kolaylaşır. Bunun üzerine sadece Sp çalıştırdığınız bir DAL (Data Acsess Layer – Veri EriÅŸim Katmanı)’nız olursa katmanlı mimarinin kolay katman deÄŸiÅŸtirme ve geliÅŸtirme ilkesine sonuna kadar uymuÅŸ olursunuz. Ayrıca kullandığınız API’nin desteklediÄŸi ölçüde veritabanı bağımsızlığını(sadece provider deÄŸiÅŸtirerek) olabildiÄŸince saÄŸlarsınız.
Benim söylemek istediÄŸim, Sp’leri olabildiÄŸince düz Sql sorgularınızı saklamak için kullanın. Business iÅŸlemlerinizin mümkünse hepsini kod tarafında tutun. Bu sayede çok daha “uygun” bir yapı kurmuÅŸ olacaksınız. Â
Burada söylemek istediğim ama konuyu dağıtmamak için söyleyemediğim şeyleri ise, veritabanı yazılımlarının nasıl yazılmaları gerektiğiyle ilgili yazmayı düşündüğüm makaleye saklıyorum.
Stored Procedure konusu oldukça tartışmalı olduğundan dolayı görüşlerinizi duymak isterim. Bakarsınız belki bir orta yol bulabiliriz 
SP kullanmaktaki en önemli amacım sql injectionı bir nebze önlemek. Biraz da takıntı, SQL kodları sql tarafında olmalı, ordan hemen görüp, düzenleyebilmeliyim, yoksa içime sinmiyor
1 satırlık bir select cümlesini için kalkıp sp oluşturmak hiç mantıklı gelmiyor bana, proje süresini de uzatıyor ama 1 den fazla sorgu veya koşul barındıran türdense mutlaka SP kullanıyorum.
Bu yaziyi ne zaman yayinladınız bilemiyorum cünkü post tarihi falan yok:S
Neyse konuya gelelim. düz sql sorgulari dediginiz sey yani kodu aplikasyon kodlarinin oldugu yere mi yazmak? Bu konuyu biraz daha açabilir misiniz?
28 Ekim 2008′miÅŸ tarihi yukarı sol köşede yazıyor
Åžimdi benim söylemek istediÄŸim kısaca ÅŸu, eÄŸer illa sp kullanılacaksa (projenin durumuna baÄŸlı bir karar bu) business logic iÅŸlemlerinin spler içerisinde olmaması gerekir. Bu durumda nesneye yönelik yapı ve katmanlı mimarinin bir olayı kalmayacaktır. Düz sql olarak kastettiÄŸim ÅŸey, tamamen crud iÅŸlemleri. Bugün birçok RMDBS’le beraber gelen sql yapısında (t-sql, pl/sql vs) neredeyse bir programlama dili kadar metod ve özellik var. ÖrneÄŸin sql içerisinde döngü yapıp kayıtları iÅŸleyebilirsiniz. Ama bu iÅŸlemi burda yapmak yerine kod tarafında yapmak daha mantıklı.
Aplikasyon kodlarının olduğu yere yazmakla neyi kastettiğinizi anlamadım ama?
Soru :
Yani sql’i uygulama kodlarinin oldugu tarafa gommekten bahsediyorum. Bunları bir örnekle açıklayabilir misiniz?
Mesela sql tarafinda kayitlari islemekten kastin nedir bussines logic nedir? Örnek bir şeyler verirsen kafamizda somut bisey olusur ve sonra dusundugumuz seyin bussines logic olup olmadigina karar verebiliriz.
Cevap :Â
Öncelikle izninle bu soruyu ve cevabı yazının altına yorum olarak
ekleyeceÄŸim.
Bir kere burada önemli olan business logic kavramı. Biliyorsundur, business logic iş kuralları demek. Yani, bir işi yaparken oluşan kurallar. Örneğin bir hastane uygulamasında hastayı kaydetmek için belirli kuralların olması lazım. Örneğin 0-6 yaş arası bebek, 6-15 yaş arası çocuk vs.
Bir stored procedure’de (örneÄŸin hasta kaydet) sql sorguları içerisinde bu kontrolleri yaparsan iÅŸ kurallarını stored procedure tarafında yapmış olursun. Normal bir veritabanı uygulamasında ise bu iÅŸlemin bir business logic layer’da bulunması gerekir. (bkz  http://www.google.com.tr/search?hl=tr&rlz=1C1CHMB_trTR347TR347&q=3+katmanl%C4%B1+mimari&btnG=Ara&meta=lr%3Dlang_tr&aq=0&oq=3+katmanl)
Örnek iş kuralı içeren sql :
IF(@YAS >= 0 AND @YAS<= 6)
SELECT …….
ELSE IF (@YAS >6 AND @YAS<= 15)
SELECT ……
…..
Bu örnek çook basit bir örnektir, iş kuralları ve yazılan sql tabi ki çok  daha karışık olabilir.
Benim savunduğum şeyse sadece native sql sorgularının yani sadece CRUD işlemlerini (http://www.itusozluk.com/goster.php/crud) gerçekleştiren sql sorgularının stored procedure olarak yazılması idi. Söylediğim kısaca, yukarıdaki örnekteki if kontrollerinin kod tarafında yapılması, sadece select sorgularının sql tarafında bulunması. Bu sayede sql sorgularını iş mantığından sıyırarak sorguların sadece CRUD işlemlerini (yani salt veritabanına yazma, okuma silme gibi işlemler) gerçekleştirmesini sağlarız.
Her kodun yazılması gereken bir yer vardır, sql tarafında iş kuralı
çalıştırılması yazıda bahsettiğim nedenlerden dolayı pek güzel bir şey
deÄŸildir. Ona kalırsa bütün kodu button’un altına yazıp geçebiliriz ama bu da sakıncalıdır.
Bunların sakıncalı olması sebebiyle design pattern  (http://www.tasarimdesenleri.com/index.action) denilen olgular  geliştirilmiştir.
İş kuralları ile ilgili daha fazla bilgi için :
http://en.wikipedia.org/wiki/Business_logic
http://www.chip.com.tr/blog/kadircamoglu/Yazilim-Gelistirme-ve-Analiz_876.html
Stored procedurelerin avantaj ve dezavantajları