Merhaba üstatlar büyük ölçekli ve sürekli gelişen bir projede programla dilinde SQL sorguları nasıl kullanılmalı? Aşağıdaki kriterlere göre benim değerlendirmelerim sonucu stored prosedüre ön plana çıkıyor. Bana göre basit bir select cümlesinde olsa stored procedure olarak yazılmalı. Düşüncelerimi gözlemlerim çerçevesinde aktarmaya çalıştım. Sizce hangisi neden? Doru ve yanlışlarım neler? Not: db Oracle 11g, programlama dili olarak C# kullanılıyor. SP kullanılsa dahi iş mantığı mecbur kalınmadıkça kod(C#) tarafında olacak.

Performans
Network Trafiği
Yönetim & Okunabilirlik
Bakım Yapılabilirlik(Test edilebilirlik)
Güvenlik
Taşınabilirlik

Performans : İki tafralı değerlendirmek gerekli DB, program kodu olarak. Benim anladığım kadarıyla DB tarafında performans olarak pek bir şey değişmiyor. Kod tarafında PQ kullanılacak sql concat veya string.format gibi string işlemleri yapılmadığı sürece performans olarak bir etkisi yok.

Network Trafiği : Burayı kaba taslak bir hesapla örnekleyeceğim; SP adı maksimum parametre adı ve parametreleri içeren sorgu isteği gidiyor. PQ da ise çalıştıracağımız sql ve parametrelerden oluşan sorgu isteği gidiyor. SP adı maksimum 32 karakterden oluşurken bir sql sorgusunun boyutu 32 karekterden çok büyük oluyor. Birde kod içerisinde düzgün görünmesi adına bir süre boşluk veya tab karakteri içerebiliyor. Bir uygulama sunucusunda bu sorgu milyonlarca kez çalışıyor ise ciddi bir trafik oluşturuyor.

Yönetim & Okunabilirlik : İki tafralı değerlendirmek gerekli DB, program kodu olarak. DB tarafı olarak baktığımızda bu konuyu tartıştığım kişiler SP sayısının düzgün bir isimlendirme standarttı olsa çok olmasının bir sorun olduğunu, karmaşık işlemlerde yani iş mantığının performans vb. gerekçelerle DB katmanında olması gerektiğinde kullanılması gerektiğini belirtiyorlar. Bu bana göre çok iş çok hata, az iş az hata, hiç iş hiç hata mantığı. Sonuç itibariyle bu sorgular her türlü Oracle vartanı üzerinde çalışıyor, SP yapmadığınızda kolayca göremiyorsunuz. Böylece sorgu ile ilgili bir sorun çıktığında veya yönetemediğinizde günah keçisi kod oluyor. SP kullandığınızda tüm sorguları tek bir noktada yani veri tabanı üzerinde tutabilir ve koddan izole edebiliriz. SP veri tabanı nesneleri olarak versiyon ayabiliriz; PQ tarafında böyle bir şansımız yok. Arama gibi işlemlerde bir sorguyu veya sorgu içinde geçen bir tabloyu SP içeresinde çok rahat arayabiliriz, QP kullandığımızda sorgularımız kodun içinde olacağından dolayı arama işlemlerini yapmak çok zor. Ayrıca QP kullanıldığında kodun ve sorgunu okunabilirliği çok düştüğünden dolayı da yönetmeniz zorlaşıyor; anlaşılamayan bir şeyi yönetemezsiniz. QP kullandığınızda bir sorun çıktığında sorguyu engelleme/Değiştirme şansınız yok; kodu tekrar düzenleyip yaygınlaştırma sürecinden geçmeniz gerekiyor.

Bakım Yapılabilirlik(Test edilebilirlik) : QP veya SP kullanılacak sorguları oluşturmak için PL/SQK Developer kullanıyoruz. Dolaysıyla burada SP hiç dokunmadan direk test/debug edebiliyoruz. QP kullandığımızda kod ve PL/SQL Developer arasında gereksiz yere copy/paste gibi manuel işlemler yapmak zorunda kalıyoruz; buda hataya çok açık bir durum. Dbabiler sql tuning açısından hangisi avantajlı?

Taşınabilirlik : Programlama diliniz değiştirdiğimizde, SP kullandığımızda kodda(istemci) tarafında tekrar tekrar aynı sorgu yazmak zorunda kalmıyoruz. İstemcinin java yada C# yazılmış olması önemli değil sonuçta biz SP çağırıyoruz. DB değiştirdiğimizde ise QP daha avantajlı dürüyor gibi fakat böyle olabilmesi için bütün sorguların ANSI sql yazılmış olması gerekli. Tüm sorgular ANSI sql formatında SP içinde yazılmış zaten basit bit tool/script ile diğer veri tabanın SP çevrilebilir. Kaldı ki kim büyük ölçekli bir projede Oracle’dan başka bir veri tabanına geçmek ister ki ?

soruldu: 25 Haz '14, 01:11

ekangal's gravatar image

ekangal
151127
cevap kabul oranı: 0%

değiştirildi: 25 Haz '14, 01:13


Öncelikle soru sormadan önceki araştırman ve soruş tarzın çok güzel. Ben iki şekilde de program yazdım. bu nedenle biraz daha tecrübemden faydalanacağım. Artık ben şu düşüncedeyim: "Veri tabanı hiç bir iş yapmaz sadece veriyi tutar.". Bu fikir çerçevesinde veritabanına hiç bir iş yaptırmamanın daha doğru olduğunu düşünüyorum.

ORM kullanılmaya başlandıktan sonra birde Çok katmanlı mimari ile uygulamanın alt yapısını güzelce hazırladıktan sonra kod yazmak çok zevkli hale geliyor. Hatta şöyle bir avantajını söyleyeyim Sp lerle çalışmamanın. Eğer herşey SP ile yapılırsa hem uygulamanda kod yazıyorsun hemde SQL yazıyorsun kodun takibi daha zor oluyor. SPler içinde kodun ne yaptığını anlamak bir işkence oluyor kimi zaman ama uygulamanın DataAccess katmanında olduğunda kodları hayat daha kolay.

Hatta yaşadığım bir şeyi daha paylaşayım seninle. Storeprocedude if ile ayrılmış bir sürü metodlar vardı. islemKodu=5 olan metodun program tarafında kullanılıp kullanılmadığını anlamak için çok saatlerimi harcamam gerekiyor yada başka yerden çağırmış mıyım diye emin olamıyorum. Ama uygulama tarafında bir metod olsaydı. Bulmak çok kolaydı. Hatta Visual Studio 2013 direk metodun üzerinde kaç kez referans edildiği otomatik söylüyor.

Söylediğin gibi gereksiz transactionlar olabilir. Cacheleme yada db katmanında indexleme filan gibi yöntemlerle bu sorunu azaltabilirsin.

Eğer ORM kullanırsa DB de bağımsızda olabilme şansız oluyor. Mesela bir metodun X databasesinden sorgu çekerken, diğer metodun Y databasesinden sorgu çekiyor. Eğer SP yazmış olsaydın SP içinden diğer Database 'e bağlanma ile uğraşacaktın.

Bence Database hiç bir iş yapmamalı sadece veriyi saklamalıdır. Bu nedenle hiç bir projemde çok sıkışmadığım sürece SP yazmam.

İyi çalışmalar.

permanent link

cevaplandı: 25 Haz '14, 03:47

M%C3%BCsl%C3%BCm%20%C3%96ZT%C3%9CRK's gravatar image

Müslüm ÖZTÜRK
10.7k103691
cevap kabul oranı: 28%

değiştirildi: 25 Haz '14, 04:21

1

+1 . "Veri tabanı hiç bir iş yapmaz sadece veriyi tutar." gibi, radikal bir yorumu birileri yapmalıydı :)

(25 Haz '14, 03:51) AliRıza Adıyahşi ♦ AliR%C4%B1za%20Ad%C4%B1yah%C5%9Fi's gravatar image

Teşekkürler. Bu kadar radikalliğe DBAdmin abilerimiz kızar mı acaba :)

(25 Haz '14, 04:17) Müslüm ÖZTÜRK M%C3%BCsl%C3%BCm%20%C3%96ZT%C3%9CRK's gravatar image

Ben sizin tarafınızdayım ama, her iki tarafıda dinlemek lazım. Çünkü benim de çok merak ettiğim konulardan birisi. Gerçekten, storedProsedure kullanmanın kritik bir gerekçesi var mıdır? Çünkü, çok çok büyük projelerde kullanılıyor (özellikle bankalarda). Bunun sebebinin klasik storeProcedure avantajlarından farklı olarak, daha kritik bir sebebi var mıdır diye merak ediyorum...

(25 Haz '14, 04:36) AliRıza Adıyahşi ♦ AliR%C4%B1za%20Ad%C4%B1yah%C5%9Fi's gravatar image

Müslüm Öztürk@Şuanda kendi standartlarımızı belirleyip bu standartlar çerçevesinde çok katmanlı mimari ile kendi uygulama alt yapımızı yazıyoruz.Kullanacağımız SP'ler için iş mantığı olmayacak(çok çok zorunlu olmadıkça)(if, else ) örneğin programda yazdığınız select cümleciğini SP haline gelireceksiniz o kadar. DB bağımsızlık bizim için önemli değil, Oracle Spatial'dan başka bir verit tabana geçme şansımız yok. Yaklaşık tablo sayısı 506 toplam boyut 3 TB

(25 Haz '14, 06:28) ekangal ekangal's gravatar image
1

Alirıza Adıyahşi@BAnkaların SP tercih etmesinin sebebi yönetebilirlik.Örneğin yaygınlaştırma bankalarda başlı başlına bir süreç. Öbür türlü bir sorgu değiştirmek için programın relase versiyonu değiştirip proda gönderene kadar bir sürü süreçten geçiyor; testler, onaylar, code review, bir çok makineye kopyalama gibi. SP versiyonlanabilmesi, SP leri DBA'ler performans açısında kolayca codereview yapabilir vb bir çok sebep.

(25 Haz '14, 06:37) ekangal ekangal's gravatar image

Şu ana kadar ki tecrübelerime dayanarak konuşursam,genelde değişiklik business kısmında oluyor.Yazılan sql sorgularında değişiklik pek sık rastladığım bir nokta değil. Eğer Db' de değişiklik yapılmış ise zaten ister istemez hem sorgular hemde business katmanı bundan etkileniyor. Yani her halükarda paket güncellemek gerekiyor. Hatta işi bir adım daha ileri götürüp tüm sorguları db'de tabloda tutanlarıda gördüm. Sorguda değişiklik olursa 'db den ufak bir update'le işi hallederiz diye savunmuşlardı arkadaşlar mantıklarını ama ufak bir değişiklik uygulamada kaç yeri etkiliyordu bilemiyordı.

(25 Haz '14, 07:02) Müslüm ÖZTÜRK M%C3%BCsl%C3%BCm%20%C3%96ZT%C3%9CRK's gravatar image
6 yorumdan 5 tanesi gösteriliyor hepsini göster

SP kullandigin taktirde isletme mantigi (business logic) veri tabanina kayar, bakimi ve gelistirilmesi zorlasir, bir veri tabani türüne bagimli hale gelir, isletme mantigi birden fazla mecraya dagitilmis olur, veri tabanindaki isletme mantiginin test edilmesi ve baska bir veri tabani sistemine tasinmasi zorlasabilir. Daha fazla performans alabilmek icin bu bedeli ödemek ne kadar gerekli, tartisilir.

permanent link

cevaplandı: 25 Haz '14, 07:06

%C3%B6zcanacar's gravatar image

özcanacar ♦♦
17.2k59183183
cevap kabul oranı: 52%

Bana göre SP ile çalışmanın hiç bir mantığı yok, bende bu konu hakkında çevremdekilerle bir kritik yapmıştım. Özcan hocamın dediği gibi iş mantığı db ye kayıyor direk olarak, ondan sonra java nın veya başka dilin üzerinde SP ler parazit gibi yaşamaya başlıyor.Bu sefer paket bağımlılıkları ortaya çıkıyor. Java üzerinden yola çıkarsam.

&&&Yönetim & Okunabilirlik : İki tafralı değerlendirmek gerekli DB, program kodu olarak. DB tarafı olarak baktığımızda bu konuyu tartıştığım kişiler SP sayısının düzgün bir isimlendirme standarttı olsa çok olmasının bir sorun olduğunu, karmaşık işlemlerde yani iş mantığının performans vb. gerekçelerle DB katmanında olması gerektiğinde kullanılması gerektiğini belirtiyorlar.

(Buradaki karmaşıklık nedir ?) Bu karmaşık işlemler, iş mantığı gerektiren işler gayet service tarafında kotarılabilir. Servisin mantığı da bu değil mi zaten, kompleks işleri SP de bırakıp servisten call mu edelim sadece, o zaman neden SOA kullanılıyoruz.

&&&&Bu bana göre çok iş çok hata, az iş az hata, hiç iş hiç hata mantığı. Sonuç itibariyle bu sorgular her türlü Oracle vartanı üzerinde çalışıyor, SP yapmadığınızda kolayca göremiyorsunuz.

Bu senin kurguladığın yapıya bağlı bir durum değil mi ? DAO katmanımız zaten Data Layer tarafında olan her şeyin adreslendiği nokta değil mi? Mesela orm de neyin çağrıldığı ortadadır.

&&&Böylece sorgu ile ilgili bir sorun çıktığında veya yönetemediğiniz de günah keçisi kod oluyor. SP kullandığınızda tüm sorguları tek bir noktada yani veri tabanı üzerinde tutabilir ve koddan izole edebiliriz.

SP dede sorun çıkabilir, hatta bu sp ler genelde paketlenir ve diğer paketlerde bunları kullanmaya başlar. Sonra ona ihtiyaç diğer paket, sonra diğer bir paket. Sonra çık çıkabilirsen işin içinden, bir şeyi değiştirirsin nerelere etkileceğini bulmak için cırmalayıp durursun sonra. Çok düzenli bir yazılım kültürü ne sahip olmadığımız için ara ki durasın sonra.

-> DAO Katmanı bu işi yeterince izole edebilir.

-> Bağımlılıklarda maven den takip edilebilir.

&&&SP veri tabanı nesneleri olarak versiyon ayabiliriz; PQ tarafında böyle bir şansımız yok. Arama gibi işlemlerde bir sorguyu veya sorgu içinde geçen bir tabloyu SP içeresinde çok rahat arayabiliriz, QP kullandığımızda sorgularımız kodun içinde olacağından dolayı arama işlemlerini yapmak çok zor. Ayrıca QP kullanıldığında kodun ve sorgunu okunabilirliği çok düştüğünden dolayı da yönetmeniz zorlaşıyor; anlaşılamayan bir şeyi yönetemezsiniz. QP kullandığınızda bir sorun çıktığında sorguyu engelleme/Değiştirme şansınız yok; kodu tekrar düzenleyip yaygınlaştırma sürecinden geçmeniz gerekiyor.

->ORM bu problemlerin hepsini çözebilir, SP dede sorun çıktığında kodu tekrar düzenleyip yine yaygınlaştırma sürecine sokmak zorundasın.

permanent link

cevaplandı: 26 Haz '14, 07:06

gklp's gravatar image

gklp
789317
cevap kabul oranı: 17%

Cevabınız
toggle preview

Bu soruyu takip et

E-Posta üzerinden:

Üyelik girişi yaptıktan sonra abonelik işlemlerini yapabilirsiniz

RSS üzerinden:

Cevaplar

Cevaplar ve Yorumlar

Yazı Formatlama

  • *italic* ya da _italic_
  • **bold** ya da __bold__
  • link:[text](http://url.com/ "başlık")
  • resim?![alt text](/path/img.jpg "başlık")
  • liste: 1. Foo 2. Bar
  • temel HTML etiketleri de kullanılabilir

Bu sorunun etiketleri:

×50

Soruldu: 25 Haz '14, 01:11

Görüntüleme: 839 kez

Son güncelleme: 26 Haz '14, 07:06

powered by BitNami OSQA