Bu yazida kisaca SP(Stored Procedure) lerin kullanilmasinin getirecegi avantajlari ve dezavantajlarina deginecegim.
Avantajları
1) Veritabanında çalıştıkları ve sorgu planları gibi bilgiler bellekte tutulduğu için veritabanındaki data ile çalışırken iyi performans sağlarlar.
2) Uygulama kodunun içinde Gömülü SQL - Embedded SQL yönteminden daha temizdir.
3) SQL kodları veritabanında tutulduğu için güvenlik açısından avantajlı olabilir.
4) SQL kodları uygulama kodun içine gömülü olmadığı için, bir veritabani sunucusundan diğer bir sunucu çeşidine port işlemleri – SqlServer dan Oracle a örneğin daha kolay ve sancısız olabilir.
Dezavantajları
1)SP lerin birim testlerini yapmak zordur.
2)Versiyonlama ve her kurulum işleminde stored procedüre ların tekrar oluşturulması gibi işlemler zaman alabilir. Bu kurulum işlemleri otomatik yapılabilirse sorunlar aşılabilir aksi halde proje ekibi kendini aynı sp nin değişik versiyonlarını kullanıyor bulabilir.
3)Taşınabilirlik – portability , Birçok proje eğer ürün amaçlı yazılmıyorsa çok nadir kullandığı veritabanı teknolojisini değiştirir. Birden fazla veritabanını desteklenmek gerekiyorsa her veritabanı tipine (sqlserveroracle vs) uygun sp leri yazmak ek çaba gerektirir. Örneğin birçok iş kuralinin (business rule ) ün sp lerde tutulduğu bir uygulamayı MSSQL dan Oracle a taşımak kolay olmayacaktir.
4)SP ler ayrı bir kod tabanı olduğu için bakım açısından ayrıca çaba gerektirecektir. Kurulum işlemleri bu yüzden daha kompleks hale gelebilir çünkü her seferinde tüm sp leri silip tekrar oluşturmak pratik olmayabilir. Çoğu projede DBA gibi ayrı bir ekip sp ler konusunda söz sahibi olacaktir.
5)Proje ekipleri çoğu zaman veritabanı ve uygulama geliştiricileri şeklinde organize olur. Bu ayrım ekibin uyum içinde çalışmasını zorlaştirir çünkü bu iki grubun öncelikleri ve çalışma şekilleri farklıdır. Bu sürece SP ler eklendiğinde uyumu sağlamak çok daha zorlaşacaktir. Birçok iş kurali(business rule) SP lere taşınırsa veritabanı geliştiricileri de sistemin gereksinimleri anlamak ve ona göre yazılım geliştirmek zorunda kalacaktir.
6)SQL iş kurallarını yazabilmek için yeterince kullanışlı bir dil değildir. SQL veritabanı katmanında (data layer) çalışır ve asıl amacı veri ile yüksek performans sağlayacak şekilde çalışabilmektir.
7)Veritabanı geliştiricilerinin çoğu birim testlerinin yazılması gibi yöntemlere hala uzaktir.
Eğer uygulamayı oluşturan katmanlar arasında veri geçişleri, üst katmanların veriye ulaşma şekli veritabanındaki yapıya bağlı olarak değiştirilmek zorunda kalıyorsa bu katmanları tekrar tasarlamak gerekir. Bir tablodaki alan/field değişikliğinden sonra eğer sunum/presentation katmanınızda değişikliklerin gerekmesi buna örnektir.9)Uygulama kodunu yazanlar(applıcation developers) iş kurallarını(business rule) ve gereksinimleri karşılamaya, DBA ler ise veritabanında tutulan verinin optimizasyonuna ve yapısına konsantre olmalıdır. Eğer uygulama kodunu yazanlar SP yazmaya kalkarlarsa optimizasyon ve performans açısından hatalar yapabilirler. Aynı şekilde SP ler DBA ler tarafından yazılır ve genel mimaride sp ler veriye ulaşma ve iş kurallarının kodlanmasında önemli bi yer tutarsa İş Alanının (business domain) in modeline uygun ve kolayca test edilebilen kodların yazılması zorlaşabilir ve kod kalitesi olumsuz etkilenebilir.
10)SP lerin tekrar tasarlanması ve yapılandırılması(refactoring) zordur. Resharper veya IntelliJ gibi araçlar mevcut değildir.
11)Debugging – Hata ayıklaması gibi yöntemler SP ler için zordur.
12)Çok az veritabanı personeli kompleks kodların yazılması ve bakımı konusunda eğitimli durumdadır.
13)Yüzlerce SP den oluşan bir SP kümesini basitleştirmek için SP ler arasında katmanlar oluşabilir fakat çoğu uygulamada zaman geçtikçe bu yöntem çöker ve bakımı zor bir yığın SP ile karşılaşılır.
14)Bir hata bulunduğunda hızlı ve küçük bir kod değişikliği ile SP ler düzeltilebilir fakat bu tür düzeltmeler çoğu zaman doğru konfigürasyon yönetim pratiklerini ve test yöntemlerini gözardı ederek yapılır. Örneğin bir hatanin Üretim/Production veritabanında bir değişiklikle düzeltilmesi fakat Geliştirme/Development veritabanında aynı değişikliğin unutulması gibi sorunlarla karşılabilir.
Peki SP leri ne zaman kullanmak mantıklı olur?
1)Bir yığın veri içinde aramalar ve güncellemeler yapmak - SP ler veritabanında olduğu ve SQL sayesinde veriye çok yakın olduğu için bu tür işler için etkili ve hızlı bir yol sunar. (Ornegin Raporlama icin verilerin alinmasi ve Batch Update gibi durumlar)
Kullanmak ne zaman hatali olur?
İş kurallarının(business rule) ların yazılması. İş kuralları Alan(Domain) Modeli ve onun üstündeki Servis(Service) katmanları tarafından uygulanmalıdır. Bu kuralların SP lerde olması daha önce sayılan nedenlerle sıkıntılar yaratacaktir.
CRUD metodlarının (Ekle,Oku,Güncelle, Sil) veritabanında Sp ler şeklinde yazılması kompleks bir uygulamada SP sayısında patlama yaratabilir. Bunun yerine domain modelininin bir O/R mapping aracı ile veya bazı kalıplarla(örneğin Data mapper, Active Record Pattern) map edilmesi daha akılcı bir yöntemdir.
Diğer tavsiyeler
Veritabanına ait kodlar uygulamayı oluşturan diğer kodlar gibi Kod/Versiyon yönetim sistemi içinde tutulmalıdır. CVS, PVCS, VSS gibi araçlarla örneğin.
Kurulum işlemleri içinde veritabanına ait kodları kuracak işlemler yapılmalıdır.( Tabloların,SP lerin oluşturulması, Test verisinin yüklenmesi gibi)
SP ler yazılıyorsa SPUnit ve DBUnit gibi araçlarla birim testlerine tabi tutulmalıdır.
Çevik veritabanı yöntemleri (Agile database techniques- Scott W. Ambler) gibi yöntemler veritabanı kısmında yapılan tasarım ve kodlamalar içinde kullanılmalıdır
Versiyonlama problemlerine karşı yeni versiyon için ayrı sema(schema) lar kullanılabilir.
Yazan : Cenk Çivici, 30.12.2004