Master/detail tablolarda sorgulama

[aLonE CoDeR]

Pardon, gayr-ı ihtiyari nedenlerden cevap yazarken bırakmak durumunda kaldım ve yeni dönebildim buraya.

Join konusunda "left join" kullanmanın da sakıncalı olacağını sanıyorum zira "inner join", olası kopmalarda meydana gelebilecek tutarsızlıkları da böylece kesmiş olacaktır.View yazma konusunda ise derlenmiş her türlü kodun özellikle de SubSQL'den çok bariz hız farkı yaratacağı kesin.Bunu bizzat kullanarak da gözlemlediğimi belirtmek isterim.Fakat benim asıl takıldığım nokta bir iç sorgunun bu kadar uzun sürede dönmesi.Kayıt sayısı nedir ve indexleme senaryosu nasıldır bilmek daha net yorum yapmaya olanak sağlayacaktır.

Kolay gele..

[aLonE CoDeR]

Aslında pek kod yazmayı tercih etmiyorum ama bu kez gerek duydum, şöyle doğaçlama bir sorgu yazarak çözülebileceğini sanıyorum, syntax hatası olabilir tabi;

Kod: Tümünü seç

Select OY.AdiSoyadi, OY.RutbeKodu, OY.Sicili, OY.Count(AdiSoyadi) as Toplam
from OlayYeri1 OY
inner join OlayYili OZ on (OY.ID=OZ.ID)
where Between OZ.IncTarihi :FirstDate and :LastDate
group by OY.AdiSoyadi, OY.RutbeKodu, OY.Sicili

Master ve Detail tabloları bağladın alanın adını "ID" varsayarak yazdım.

Kolay gele..

[bobasturk]

Merhaba,

@aLonE CoDeR teşekkür ediyorum ve bilmeni istiyorum ki sizlere hazır kod yazdırarak bu işin altından kalkma amacı gütmüyorum. @mrmarman ustamın verdiği kod bloğu ile şunu öğrendim, Sorguda iç select uygulamasını. Gaye öğrenmek, öğrenebilmek içinde önce bilmediğini itiraf edip söylemek ve sonra sizin gibi bilenlere sormak ve araştırmak.

Verdiğiniz kod bloğunu kendi tablolarıma göre uyguladım ilk söylediğim ve yazdığım kodlar gibi tarihsel şartı koyduğunda sonuç null dönüyor, tarihsel şartı vermediğinde tüm kayıtların toplamını veriyor.

Şöyle bir yol düşünülebilir gibi tabloları join ile birleştirip memtabloya yazdırmak daha sonra tarihsel aralıkta sorguyu çekmek. Ne kadar sağlıklı olur ve hız açısından iyi olur bilmiyorum ama aklıma gelen bu. Bir ikinci çözüm ise önce de bahsettiğim gibi detail tablolara inctarihi alanı ekleyerek kayıt esnasında bu tarih alanı değerini ana tablodan almasını sağlamak ve direkt detail tabloya tarihsel aralıkta sorgu çekmek.

View yazma konusunu hiç bilmiyorum ve uygulamadım. Bu konu üzerinde de biraz çalışma zamanı geldi sanırım.

Teşekkür ve saygılarımla kolay gelsin

[mrmarman]

@aLonE CoDeR

- Bu kadar olgunlaşmış bir mesaj dizisinde kod yazmaktan çekinmeyelim. Hatalı olabilir önemli değil, keza temrin değeri var.

- Benim de merak ettiğim seninki ile aynısı açık söyleyim. İstediğim testler hangi kısmın beklemeye sebebiyet verdiğini anlamak içindi. Sonuç alındı artık irdeleme için başlangıç noktası var.

- Burada sadece minik bir sorum olacak. Inner Join'in yeri ayrı Left Join'in yeri ayrı. Kulvarı farklı iki sorgu tipinin kopma şeklindeki ifadenizle ilişkili bir tutum sergileyeceğini örneklemenizi istiycem.

- Burada Left Join önerisi başlangıç seviyesinde bir kurgu için olduğunu söylemeyi ihmal etmiş olabilirim.

- Yani Bir Join işlemini test için şahsen önce Left Join ile elimdeki verinin boyunun ölçüsünü alır ondan sonra sadeleştireceğim kısımları görüp başka strateji kurmam gerekli mi?yi iredelerim. Uyguladığım genel metod budur.

- Left Join'in görevi soldaki tablonun tümünü sergileyip, sağdaki tablonun eş değeri varsa olan veriyi ekleyip sergilemek üzerine olduğunu hepimiz biliyoruz değil mi ?

- Inner Join ise soldaki tablonun tüm verilerini alırken, sağdaki tabloya ait şart doğru değilse listede göstermemek üzerine bir kurgu olduğuna ve buna göre eksik veri çıkması demek olduğunu biliyorum. Yanlış biliyorsam düzeltin.

- Örneklemek gerekirse

Kod: Tümünü seç

SELECT T1.Adi
FROM T1
INNER JOIN T2
ON T1.ID=T2.ID
WHERE T2.Urun = 'mouse'

eşittir

Kod: Tümünü seç

SELECT T1.Adi
FROM T1, T2
WHERE T1.ID=T2.ID
AND T2.Urun='mouse'

oluyor yani Urun mouse ile eşit değilse o satır listelenmiyor. Left Join ile bu sorgu farklı şekilde yapılabilirdi o satır görüntülenecek fakat ürün kısmı boş kalacaktı.

- Farkı bilmeyenler için açıklayıcı olsun diye örnekledim. Burada sıkıntı yaratacak bişey yok.

[aLonE CoDeR]

Tekrar selamlar.

Yanlış anlaşılma olmamasını istirham ederek başlamak gerektiğini düşündüm.Kod vermek konusunda bu benim genel yaklaşımım ve prensibim diyeyim.Ancak sizinle aynı düşüncede olduğum için kod örneğiyle düşündüğüm senaryoyu pekiştirmek istedim.Özetlemek gerekirse eğer burada yazılan kodlarla bunu geliştireceğin düşüncesi oluşsaydı kod örneği vermeyi tercih etmezdim yine...Ek olarak bizim bilgimizin doğru olması gibi bir kural malumunuzdur ki yok..

@mrmarman;

Join konusunda söylediklerinle benim bildiklerim aynı.Burada altını çizmek istediğim tek bir nokta var ki, Türkiye'de yazılım kurallarını tam olarak uygulamayazsınız!Neden uygulayamazsınız?Çünkü illegal şeyleri de kullanıcıya sunmak zorundasınız.

Master/Detail ilişkili bir tabloda herhangi bir şekilde veri tutarsızlığı meydana geldiğinde; "left join", master tablonuzda olmayıpta detail tablonuzda olan kayıtların da toplama dahil edeceğini, böylece yanıltıcı bilgilerin döneceğini, edindiğimiz tecrübelerden yola çıkarak rahatlıkla söyleyebilirim.Bu nedenledir ki "left join" yerine "inner join" kullanmak daha sağlıklı bir sonuç döndürecektir.

Soruya tekrar dönersek;

Yukarıdaki örneğin uygulanmasında null dönmesi iki ihtimali ön plana çıkarıyor, ya senaryo tam oturmadı ya da master/detail ilişkisinde yukarıda bahsettiğim tutarsızlık sözkonusu.Biraz daha irdelemek gerekecek sanırım ancak elimizdeki donelerle daha fazla yorum yapılamadığı da aşikar...