From: Yüksel ÖZCAN (yukselozcan@celiknet.com)
Date: Thu 18 Sep 2003 - 10:17:14 EDT
> Merhaba,
Merhaba
> Mysql (ve digerlerinde de) icin bu kadar az bir kayitta arama yapmak
> cerez bir istir. O yuzden bence sorgu sonucunda ne kadar cok kayit
> cekilirse mysql'den cekeceginiz veri miktari buyudugunden o kadar
> yavaslamali. Yani 500 sonuc 100 sonuctan daha yavas gelmeli. Ama 500
> sonuc, hatta 5000 sonucta eger text/blob alanlarda buyuk veriler
> tutmuyorsaniz cok ufak bir rakam. :)
Ben de onu diyorum işte. Verdiğim bir örnekti sadece. Az olan kayıtlar daha
çabuk gelmesi gerekirken çok olan kayıtların çekilmesinden daha geç
gelmektedir. Orantısız bir durum var. Çok işi kısa zamanda, az işi çok
zamanda yapıyor.
> Algoritmalarinda hata olabilir. Ama SQL ile tek satirlik bir sorgu
> bu. Logo gold hangi veritabaninda calisiyor?
Logo gold pervasiveSQL'de çalışıyor. Sizce logo gold şöyle bir mantık
izlemiş olabilir mi;
gtk'daki clist gibi düşünün. Önce öntanımlı liste geliyor(cliste basılıyor).
Daha sonra liste ekranda iken listenin altındaki filtreler düğmesine
bastığımızda açılan pencerede filtreleri tanımlıyoruz. İşte dananın kuyruğu
bundan sonra kopuyor. Benim düşündüğüm şu; Program liste ekrana geldikten
sonra - filtreleri tanımladıktan sonra listeyi sıfırlayıp tanımlanan
filtrelere göre yeniden sorgu göndermek yerine gtk_clist gibi bir bileşen
üzerine alınmış olan raporda her satırı tek tek yeni filtreye göre denetleme
yoluna gidiyor. Programın dediğim gibi sürünmesinin sebebi de sanırım bu.
Eğer Logo böyle birşey yaptıysa sebebini bilmiyorum ama hiç te akıl karı bir
şey değil. Yazılım firmalarının nasıl bir mantık güdebileceği konusunda bir
fikrim yok. Fakat böyle bir kısmın böyle yavaş çalışması durumuna da başka
bir açıklama bulamıyorum. Sizlerin daha iyi bir fikri olacağını düşündüğüm
için sizlere de danışayım dedim. Teşekkür ederim.
> sevgiler
>
Yuksel ÖZCAN
http://muhasebeci.geleceklinux.org