Rushmore optimizasyon düzeyi

Cevap yazarken Ali'nin aklima "Cetin'den bize firsat kalmiyor" lafi geliyor ve cekiniyorum aslinda, biraz firsat tanisam diye ama senin simdi ihtiyacin var:)

Sende full optimizasyon degildir, cunku "Set deleted ON" konumundadir ve deleted() ile ilgili bir indexin yoktur. Once Set Deleted OFF yap ve sys(3054)'e gene bak. Bu sadece nedenin o oldugunu garantilemek icin, sonra gene "Set Deleted ON"a don.

Ne yapman gerekiyor (Benim soyleyeceklerimin bir kismi gayri resmi sinifi aciklama yani kitap bilgisi degil):
a) ONCELIKLE hafiza degiskeni kullandigin yerlerde m. kullanmayi aliskanlik haline getir. Bunu tartismaktan yoruldum, kullanmazsan kendin bilirsin:)

SELECT DISTINCT BIOPSINO FROM YERTANI WHERE YERKODU=m.lcYer ORDER BY BIOPSINO

b) Bu durumu gormezden gelebilirsin. Bunu senin 'full', 'partial' gormen degil, gercek hayatta aldigin performans belirler. Sorgularin ne kadar suruyor, su anki data boyutu nedir, ortalama aylik eklenen miktar nedir gibi bilgiler ile buna ancak kullanim testleriyle karar verebilirsin.

c) Full gormeyi tercih edebilirsin:) O zaman silinmis kayitlar icin de index gerekiyor. Indexler ilac gibi, dozunda kullanmak gerekiyor, fazlasi da zarar.
Silinmis kayitlar icin kullanmayi tercih edebilecegin iki tip index var:

1)

INDEX on DELETED() TAG 'removed' binary

2)

Index on deleted() tag 'removed' for deleted()

3) Daha once soyledigim, 'partial' gormeyi dert etme.

Deleted() sonucu logical yani sadece TRUE ve FALSE degerlerini iceren bir indexten bahsediyoruz. Bir indexteki deger cesitliligi azaldikca indexin seciciligi de azaliyor ve zararli hale gelmeye baslayabiliyor. Mesela tablodaki kayitlarin yarisi silinmis ise boyle bir index zaten kayitlarin yarisini secen bir index, indexin server'dan indirilmesi daha cok zaman kaybettirir. Binary index yaparsan (ki Binary indexler ozellikle logical alanlarin indexlenmesindeki performans sorunu icin yapildi) cok daha efektif bir indexin olacak ve daha hizli sonuclar alirsin. O konuda VFP yardiminin aciklamasi, eger donen kayitlarin sayisi %3 ustunde ise VFP'nin index kullanmadan kendisinin sorgu sirasinda lokalde bitmap index yaratmasinin daha hizli oldugunu soyluyor. Eger beklenen kayit sayisi %3 altinda ise (iki bu oran tablo buyudukce daha da dusebilir-mis) o zaman binary index daha hizli.  Ozeti, eger tablodaki beklenen silinmis kayitlarin sayisi %3 altinda ise BINARY index kullan. Uzerindeyse birak daginik kalsin - pardon Rushmore'un mesajini takma diyecektim:) Diger filtrelenmis index'i acikcasi ben kendim hic kullanmiyorum ama o da bir optimizasyon.

Cok uzattim:) Son olarak soyleyecegim, silinmis kayitlarla ilgili index yapmali mi, yapmamali mi vs belli bir kurala bagli degil. Kendi ortaminda test et, en uygununu sec.

Her zamanki gibi hem textbook gibi hem de pratik açıklamalarınız nedeniyle başta Çetin'e (senli benli yazışmaya da alışamadım ama ben de başladım) çok teşekkür ederim.
1. SET DELETED ON yapınca full optimizasyon oldu . Ben dediğiniz gibi yine SET DELETED OFF'a döndüm.
2. Bu dosyaya aylık 2000-2500 gibi kayıt olacak. Aslında bu tabloda birkaç field daha var ama bir kaydın boyutu ya da field'ların toplam karakter sayısı 60 byte civarında. Yani çok küçük bir tablo, search'ün hızlı olması için özellikle küçük tuttum. Deleted kayıt sayısına gelince, ayda 20'yi geçmez (yani binde bir). Bu durumda SET DELETED OFF'ta bırakıp optimizasyonun partial olmasına aldırmamayı düşünüyorum.
3. lcYer yerine aslında laYERKOD[1] gibi bir array vardı ben sorumu sadeleştirmek için böyle yazmıştım. Aslında değişkenlere m. takısını çoğunlukla kullanıyorum. Burada bir sorum daha olacak array için de m. yazmak gerekir mi?
Yani doğrusu m.laYERKOD[1] mudur?