view ve query
serbek_tr01.02.2005 - 17:59:04
Selam Dostlar formda viewlar hakkında bir aram yaptımda bir kaç tanesinde view ile query den sorgu çekme arasında pek fazla bir fark olmadığını belirtmiş ben bir deneme yaptım arkadaşlar yine şunu söyleyeyim view sonuçlarının gride yansıması 10 sn sürmedi ancak aynı iş query ile 106 sn yi buldu neyse burası bir nottu bilinmesi gerekn bir şey olabilir diye söyledim aslında bu fark yerel ağ bağlantısındada 3-5 sn kadar fark yapıyor ama net üzerinde gördüğünüz gibi 96 sn kadar bir fark var.

yalnız arkadaşlar grid in DrawColumnCell olayında yaptığımız bir takım olaylar işin içine view girince gerçkleşmiyormesela x alanının degeri 0 ise satırı kırmızı yap gibi neden çünkü viewda kayıt sürekli en başta konulu kalıyor ve bütün satırlar ilk kaydın durumuna göre değerlendiriliyor fetchall klullandım olmadı oda sadece recordcoun bilgisinin sağlıklı alınmasına fayda sağlıyor yoksa recordcount da sürekli 1 de kalıyor yada gridde hangi kayıtta olursan ol fark etmez query (query içinden çağırıyorum view'ı) ye edit dediğin zaman hep 1. kayıtı edit ediyor bunu bir çözümü varmıdır
 
Anonymous02.02.2005 - 09:44:45
merhaba.

formda viewlar hakkında bir aram yaptımda bir kaç tanesinde view ile query den sorgu çekme arasında pek fazla bir fark olmadığını belirtmiş ben bir deneme yaptım arkadaşlar yine şunu söyleyeyim view sonuçlarının gride yansıması 10 sn sürmedi ancak aynı iş query ile 106 sn yi buldu neyse burası bir nottu bilinmesi gerekn bir şey olabilir diye söyledim aslında bu fark yerel ağ bağlantısındada 3-5 sn kadar fark yapıyor ama net üzerinde gördüğünüz gibi 96 sn kadar bir fark var.


hocam view en sık kullanılan sorguları tekrar tekrar yazmaktan kaçınmak için tercih edilen bir yöntemdir (bildiğim kadarıyla).sonuçta aynı sorgu çalışacağına göre bu kadar bir farkın olacağına pek ihtimal vermiyorum,emin olmasam da..

kolay gelsin.
 
serbek_tr02.02.2005 - 10:10:45
Üstad bende forumda okuduklarım itibari ile öyle düşündüm Hatta fahrettin abi de bununla ilgili bir şeyler yazmıştı tekrar edilen raporların hızlı bir şekilde alınması haricinde fark yaratmayacağı tarzında bir şey yazmıştı (Yanlışım varsa özür dilerim Fahrettin abi ).

Ama denedim denediklerim üzerine konuşuyorum izmirden bağlantı yapılmasını sağladım benim ana makinaya iki exe verim biri select * from tblx diğeri select * from Viewx yani biri tablodan biri viewdan aldı abartmıyorum zaman tuttuk biri 106 sn açıld biri 10sn toplam field sayısı 20 kayıt sayısı 2724 ve tüm field lar gerçek verilerle dolu sadece bir fark var arada tablodan bilgi açan exede grid üzerinde hücre işlemleri var ancak onlarıda kaldırıp denedim buğün sadece 76 sn düştü
 
onaydin02.02.2005 - 12:07:13
Atıyorum (tutturacağımı umud ediyorum :) )
bir sorgu çalıştırdığınızda veritabanı önce bunun bir planını oluşturuyor, where ve order by a göre bir plan hazırlıyor ve kayıtları ona göre getiriyor.
Table dan çektiğinizde her defasında bu planı oluşturması gerekiyor, view kullandığınızda bu planı view oluşturulurken oluşturduğundan işin o kısmıyla ilgilinmiyor olabilir.
 
serbek_tr02.02.2005 - 12:12:47
Sayın Onaydın view bildiğim kadarı ve firebird den anladığım kadarı ile size katılıyorum burdaki amaç zaten anladığım kadarı ile bir takım işler veritabanı kısmında arayüze göre daha hızlı oluyor bu lokal networkte fazla fark yapmıyor belki ama ben yinede kayıtlarım dolu dolu olduğu için bu farkı en fazla 3-5 sn kadar fark ediyorum ama dediğim gibi bu farkın alasını uzak erişimde gördüm birde şunu anladım ki uzak erişimde kayıt listelenecekse sadece listeleme amaçlı olması hızda büyük fark yaratıyor atıyorum bir grid üzerinde kayıtlara göre renk vs işlemler uzak bağlantıyı haddinden fazla kastırıyor.

katılım ve görüşleriniz için teşekkür ederim
 
fahrettin02.02.2005 - 13:01:25
Bu derece bir fark hakikaten olmaması gerekiyor..... Zira view'in query'ye göre tek farkı view daki sql cümlesinin kompile edilmiş ve query planının hazırlanmış olmasıdır....

Bu farkın sebebi olarak ise aklıma gelen çalıştırdıgınız query nin server tarafında degil de client tarafında çalışıtırlmış olması ihtimalidir.... Mesela BDE de böyle bir ayar var. SQLQRYMODE bunu lokal veya server secebiliyorsunuz.... Eger Delphi versiyonunuz Client server veya enterprise degilse query yi lokalde çalıştırıyor ve veritabanı tarafına gönderemiyor olabilirsiniz diye tahmin ediyorum.....
Ya da başka bir fark olmalı....

Şunu deneyin..... IBExpret icinden deneme yapin....

Select * from MYVIEW
ile view dan select edin sonra da view in kodunu aynen calistirin... Arada süre farkı olmaması gerekiyor.... Sizin elde ettiginiz farkın sebebinin de veritabanından kaynaklanmayan dış etkiler oldugunu ispat edecektir bu deney.... Yani inşallah.... :)
 
serbek_tr02.02.2005 - 13:56:53
SAyın Fahrettin Abi Sözüm doğru yada yanlış(Eksik) olabilir herzaman sözmünn arakasındayım eğerki bulduğum bir noksanım varsa onuda hiç çekinmeden belirtirim. Ve Şuan belirtiyorum bu farkın sebebini buldum Embarassed bu arada delphi Enterprise.
Sebeb şu unutmuşum farkında değilim asıl query içinde lookup field lar varmış
view de kullandığım query de bunları eklemeyi unutmuşum hepinizden özür dilerim ancak fark şu şekilde olduikiside lookup olunca durum 76 - 48 view eksik skorla önde. Embarassed tamam artık fazla bir fark yokmuş.
Ama artık bir sorun daha var şimdi biz uzak bağlantıda lookup filed kullanamaycakmıyız şimdide lookup fieldlar zaman farkı yaratıyor.

Fahrettin abiciğim bu işin üstadı olarak bir öneri istiyorum bu lookup field olayına nasıl bir çözüm getirebiliriz yada daha kullanışlı bir yöndetem varmı
şimdi lookupfield niye kullanıyorsun diyecek olursanız DovizTürü, Gurup,Özelkod,lot gibisinden bilgileri başka yerde tuttuğum için bunların sadece Id sini stoğa yazıp isimlerini lookup ile getiriyorum daha pratiği varmı
 
fahrettin02.02.2005 - 14:21:54
Estağfirullah.....
tam yapmak istediginiz gibi bir iş yapmıştım. İnternet üzerinden baglandigim bir veritabanı uzerinden Delphi programı çalışıyor ve de bir suru lookup alan vardi.....
Uzun denemeler ve arastırmalar sonucu geldigim nokta su :
TUpdateSQL kullanmak....
Query'nizin icinde lookup alanlarınızı da join yapıp cekeceksiniz.... Yani
Select P.AD, P.BOLUM_NO, B.BOLUM_AD as BOLUM_ADI
from PERSONEL P, BOLUM B
where P.BOLUM_NO=B.BOLUM_NO
şeklinde.... Bolum adını göstereceksiniz fakat sadece BOLUM_NO alanını update edeceksiniz.... TUpdateSQL kullanımı ile ilgili forumda ornekler vardi zaten....

Peki nasıl bir hız beni bekliyor derseniz ben sonuç karşısında çok ciddi olarak şaşırmıştım diyebilirim..... Cidden çok hızlı çalışıyor... Tabi formunuzda hic Table filan olmamalı ve hic lookup tanımlanmış olmamalı butun lookupları join ile cozmelisiniz....

Kolay gelsin....
 
serbek_tr02.02.2005 - 15:21:40
Fahrettin Abi çok teşekkür ederim, Bende zaten lookuplar olmadan denedim gayet iyi çalışıyor ancak lookuplar işi bozuyor tavsiyeniz çok işime yarayacak tekrardan Çok TEŞEKKÜR ederim.

Bu arada yeni bir soru sormaktan geri kalmıyorum bir den fazla lookupfield için nasıl bir kod yazmam gerekecek
 
fahrettin02.02.2005 - 16:06:59
Mantık aynı ana tabloya lookup olan alanların ilgili tablolarını from kısmına ekleyeceksiniz....
Select P.AD, P.BOLUM_NO, B.BOLUM_AD as BOLUM_ADI , P.SEHIR_NO, S.SEHIR_AD as SEHIR_ADI
from PERSONEL P, BOLUM B , SEHIR S
where P.BOLUM_NO=B.BOLUM_NO and P.SEHIR_NO=S.SEHIR_NO
 
serbek_tr02.02.2005 - 17:37:25
Fahrettin Abi çok teşekkür ederim Emeklerini helal et abi
 
fahrettin03.02.2005 - 11:11:30
Estağfirullah.... Helal olsun......
 
serbek_tr07.02.2005 - 09:46:22
Fahrettin Abi denedim birden çok lookup alan için sonuç gelmiyor sebeb ise lookup alan karşılığı değeri girilmemiş ise böyle oluyor lookup kontrolu olan alanların değeri boş isede gelmesini istiyorum bunun için ne yapmalı
SELECT
s.*, O.ADI AS OZELKODADI, D.DOVIZ AS SATISDOVIZADI,
D.DOVIZ AS MALIYETDOVIZADI, L.KOD AS LOTADI

FROM
TBL_STOK_KARTI S, TBL_OZEL_KOD O, TBL_DOVIZ D,
TBL_LOT L

WHERE
(S.OZEL_KOD=O.ID) AND(S.SATIS_FIYATI_DOVIZ_TURU=D.ID) AND (S.MALIYET_DOVIZ_TURU=D.ID) AND(S.LOT= L.ID)

ORDER BY
S.KOD
 
fahrettin07.02.2005 - 13:11:30
Eger lookup alanlara deger girilmemesine ragmen query sonucunun o satiri getirmesini istiyorsak ki bu durumda dogal olan talep budur. Bu durumda outer join kullanmalısınız.... Forumda aratarak veya 6. Eğitim seminerini izleyerek bu konuda detaylı bilgi edinebilirsiniz.... Join tipleri vs....

kolay gelsin...
 
serbek_tr07.02.2005 - 16:34:49
Fahrettin abi cevap vermekte yada düzelteme yapmakta geç kaldım özür dilerim, zaten arama yapıp sonucu alacak şekilde bir sorgulama gerçekleştirdim, ancak yanılmıyorsam bu yaptığım, sonuç hızını olumsuz etkileyecektir bunu tam olarak bilmiyorum ama sizin önerdiğiniz şekilde yapılınca sonuç çok hızlı geliyordu belki join olaylarına gerek kalmadan yapılabilir mi düşüncesi ile sormuştum ancak başka çare görünmüyor galiba birde aynı tablodan farklı iki lookup için ayrı tanımlama yapmaktan başka çare yokmu onu merak ettim mesela döviz tablosundan hem satış için hemde maliyet için iki lookup tanımlanacak ancak bu durumda tablo adını iki kere kullanmam gerekti bunu *** ile belirttim
SELECT
S.KOD, S.BARKOD, S.AD, S.BIRIM,S.OZEL_KOD, S.KRITIK_MIKTAR,
S.SATIS_FIYATI_DOVIZ_TURU, S.MALIYET, S.SATIS_FIYATI,
S.KDV_ORANI, S.ISKONTO, S.MEVCUT, S.LOT,
S.MALIYET_DOVIZ_TURU,
O.ADI AS OZELKODADI, D.DOVIZ AS SATISDOVIZADI,
DD.DOVIZ AS MALIYETDOVIZADI , L.KOD AS LOTADI
FROM
TBL_STOK_KARTI S
left outer join TBL_OZEL_KOD O ON (S.OZEL_KOD=O.ID )
left outer join TBL_DOVIZ D ON (S.SATIS_FIYATI_DOVIZ_TURU=D.ID )***burası ve bir alt satır
left outer join TBL_DOVIZ DD ON (S.MALIYET_DOVIZ_TURU=DD.ID )
left outer join TBL_LOT L ON (S.LOT=L.ID )
ORDER BY
S.KOD


ve çok fazla join oluşu sorgu sonucunu yavaşlatırmı
 
fahrettin08.02.2005 - 10:58:45
aynı tabloya birden fazla join kurabilirsiniz.... her bir joine farkli alias vererek bunu halledebilirsiniz...
TBL_DOVIZ D ve TBL_DOVIZ DD ile bunu yapmissiniz zaten....

Joinin fazla olmasi problem degil... Yani bu gonderdiginiz koddakilere fazla join denemez... Bunun 4-5 kati adette join ve alt sorgularda da bir o kadar join yaptigimi bilirim.... Sonucta bu iliskiler var ise bunu query icinden join yapmaktan daha hızlı hic bir sekilde sorgulayamazsınız...

Yalnız gerekli indexlerin olmasi onemli tabi ki... Yani join alanlarının her iki tabloda da index olmasi gerekir....
 
serbek_tr09.02.2005 - 10:06:13
Peki Hocam Rahatladım teşekkür ederim ancak her iki tarafta da index olayını tam olarak bilmiyordum açıkçası ama bu demekki asıl tabloda sırf lookup lar yüzünden index sayısı artacak.

Teşekkür ederim Fahrettin Abi
 
fahrettin09.02.2005 - 12:33:02
Eger sadece bir join olsaydi ana tabloda indexe gerek olmayabilirdi.... Fakat olasi ic ice queryler, order by lar filan derken hangi asamada ana tabloda lookup alanın indexine ihtiyac olacagini farkedemeyebiliriz. Bu yuzden daha veritabanı tasarımı aşamasında bu tur ilişkiler için her iki tarafa da indexleri koymak ileriye yönelik performans açısından iyi bir önlemdir...
 
serbek_tr09.02.2005 - 17:36:08
Peki Fahrettin Abi Herşey için çok Sağol, Sağlıcakla Kalın İnşallah
 
NOT : Bu sayfa google'un siteyi indekslemesi içindir. www.delphiturkiye.com/forum/ adresini kullanınız!
1998-2006 www.delphiturkiye.com