Re: [Linux-programlama] MYSQL Sorgusunda istediğim sonucu alamıyorum

---------

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Serdar KÖYLÜ (serdarkoylu@fisek.com.tr)
Date: Wed 08 Dec 2004 - 16:56:42 EET


Selamlar..

Sorun, "optimizasyon" ile "olması gereken" arasındaki fark. Veya bu
farkın farkında olmamak. Ev yaparken çatı yapılır. Bu "Vay efendim, kış
gelirse düşünürüz" diye atlanmaz. Sonuçta, kış gelmeden, sinek derdi
başınızı ağrıtır. Kötü olan ise siz bu derdin, sineklerden
kaynaklandığını sanırsınız. Çatının o işe faydası olacağını ihmal
edersiniz.

Maalesef, yazılım geliştirmede bu gibi durumlar ÇATI gibi açık ve net
olmazlar. Durum, depreme dayanıklı ev yapmak gibidir. Zemin, beton
kalitesi, etriyesi ıvırı zıvırı... Sıradan insan için her toprak
aynıdır, toprak topraktır. Sıvılaşma vs. ne ola ki?

Programlamada bu, "Çalışıyor işte.." lafı ile özetlenir. Veri
tabanındaki X satırı alıp, dosyaya yazıp, sonrada system("cat dosya|grep
data") yazmakta çalışan bir sorgulama yapmaktadır nihayetinde. Sonuçta,
doğru olmadığı sürece, o örnek kod ile, cat örneği benim gözümde
kötüdür, yazılmamalıdır, kabul edilemez.

İşte durum bunun gibidir. Optimizasyon ise, mesela camlara korkuluk
takmak, kapıya görüntülü diafon koymak, asansör tertibatı yapmak vs.
gibi işlerdir. 100 katlı bir binada asansör olmadan da yaşanır. Mesainin
2/3'ü merdivende geçer sadece. İşte optimizasyon buraya bir asansör
koymaktır. Ama çelik iskeleti, kapıyı pencereyi "optimizasyon"
sayamazsınız.

Bu tür kod yazmak, işte öyle ev yapmaya benzer. Benim belirttiğim gibi
kavramlar optimizasyondan daha aşağıda kavramlar. Eğer tüm uygulamayı
görseydik, o zaman belki optimizasyon denebilecek seviyede tavsiyelere
girişebilirdik. Ama genel kural olarak şunu söyleyebiliriz. Angarya kod,
gereksiz her bayt, lüzümsuz her satır/işlem vs. yanlıştır. Yanlış,
yanlıştır; "daha kötü" ile eşanlamlı değildir.

Sorun, yanlış yapmaktan kaçınmayı bir disiplin haline getirmektir.
field'i INT yaparken neden sorusunun cevabı, "Bu bir sayıda ondan"
cümlesiyle özetlenemez. Her şeyin cevabı, yeri, kapsamı vs. belirli
olmalıdır:

SELECT * FROM HEDE WHERE f1=p1 or f1=p2 or f1=p3 or f1=p4

Burada p3 ve p4 seçilmemişse, Bunları işleme koymak yanlıştır. Ama
optimizasyon derseniz, mesela, istatistik olarak veritabanında en fazla
sayıda olduğunu bildiğimiz f1 == p3 durumuna ait işlemin en başa konması
bir optimizasyon olabilir.

Bilmem anlatabildim mi? Mesele disiplin meselesi. Burada doğru yolu
göstermek önemli; bir satır SQL'i parantez içine almamışsın demek sorunu
değil yani asıl sorun..

Saygı ve sevgiler..

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Var bende öyle bir örnek. 2 yılda sadece 18-19 MB'lık veri oldu
> veritabanında. Ben kurulumu yaparken bunu öngördüğüm için yaptım biraz
> ayar, 2 yıldır aynen çalışmaya devam ediyor. Ancak, sürekli yeni sorgular,
> yeni uygulamalar gelir, onların nasıl çalıştığını görmek isteriz, o zaman
> durum tabii ki değişir. Kişisel düşüncem, Türkiye'de birçok veritabanının
> optimizasyon gerektirmeden çalışacağı :) Aman ben o konuya girmeyeym
> şimdi.
>

_______________________________________________
Linux-programlama mailing list
Linux-programlama@liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

---------

Bu arsiv hypermail 2.1.2 tarafindan uretilmistir.