Tabloyu sisirip testlet yapıyorum, zaten yazdıklarım da bu bilgiler ısıgında:)
Yani ozetle
SELECT * FROM tablo WHERE x='1' OR y='1' YERÄ°NE
SELECT * FROM tablo WHERE x='1' UNION SELECT * FROM tablo WHERE y='1'
seklinde bir kullanım cok daha performanslı calisiyor. Neden derseniz.
İlk sorgu tum taboyu eksiksiz tararken 2. sorgu x'in 1 e esit oldugu kısıtlı kayıt ile ynin 1 e esit oldugu kısıtlı kayot sonuclarını birlestiriyor.
Bu durumda UNION kesinlikle daha performanslı.
PMA cıktısına gore 1. sorgu 0.15sn surerken, 2. sorgu 0.002sn suruyor.
Sorum ve sornum ise su, arama yapılan bi cok formda x=1 OR y=1 OR z=1 OR gdie gidiyor. Bu da anlıyorum ki tum tabloyu her zaman işlemeyi gerektiriyor. Bu durumdanapmak lazım? x'lerin 1 oldugu ek tablolar acmak acaba gercekten mantık lı mı?
Bu konuda hakkında her turlu yorumu merakla bekliyorum
OKAN ARI
----- Original Message -----
From: Uygar UZUNHASAN
To: linux-programlama_at_liste.linux.org.tr
Sent: Saturday, December 29, 2007 6:41 PM
Subject: [Linux-programlama] Re: SQL'de OR kullanýmý ve performans
Ben bu işin uzmanı değilim (nasıl çalıştığını bilmiyorum) ama muhtemelen OR dediğinizde UNION çalışıyordur yani otomatik olarak bu şekilde arıyordur. Sonuçları ms ler bazında olan sorgularda zaten sorun değil. Size tavsiyem tabloyu şişirip ikisini de ayrı ayrı test etmeniz, (mesela öyle bi sorgu yazın ki sonuç 40-50sn sürsün) sonra da bizlerle paylaşmanız.
Uygar UZUNHASAN
uygaruzunhasan_at_yahoo.com
----- Original Message ----
From: OKAN ARI <liste_at_ari-tech.com>
To: linux-programlama_at_liste.linux.org.tr
Sent: Saturday, December 29, 2007 6:01:18 PM
Subject: [Linux-programlama] Re: SQL'de OR kullanýmý ve performans

Tesekkurler, peki soyle bir mantık mı yurutmek lazım. OR kullanmak yerine UNİON ile tabloları birlestirmek her zaman daha iyidir? Zira bu seklde cidden sadece sql bazında cıkan ufak kayıtlar birlestirildi.
Ancak bası sırgularda 10 larca OR var. Buların her birini UNION ile birlestirmek mantıklı mıdır? Yoksa duruma gore sekilendirmek mi lazım?
----- Original Message -----
From: Uygar UZUNHASAN
To: linux-programlama_at_liste.linux.org.tr
Sent: Saturday, December 29, 2007 5:52 PM
Subject: [Linux-programlama] Re:SQL'de OR kullanýmý ve performans
SELECT * FROM tablo WHERE x='1'
UNION
SELECT * FROM tablo WHERE y='1'
Uygar UZUNHASAN
uygaruzunhasan_at_yahoo.com
----- Original Message ----
From: OKAN ARI <liste_at_ari-tech.com>
To: linux-programlama_at_liste.linux.org.tr
Sent: Saturday, December 29, 2007 5:08:05 PM
Subject: SQL'de OR kullanýmý ve performans
Ornegin 10.000 kayÅtlÅ bir tabloda SELECT * FROM tablo WHERE x='1' OR y='1'
die bi sorgumuz olsun.
Biliyoruz ki aslÅnda x='1' olan 14, y='1' olan 10 kayÅt var.
Bu sorgunun yanÅtÅ bulnurken tum 10.000 kayÅt tek tek inceleniyor (EXPLAN ile gordugum). Bu da son derece ciddi br performans dususune neden oluyor. Bu baglamda
SQL'de OR kullanmak bu kadar performans dusuruyorsa (ki boyle bir reel tabloda sorgu 0.15sn suruyor) bunun bir cozumu olmalÅ die dusunuyorum. Topamda max 24 kayÅt verecek bir sorgu icin 10.000 kaydÅn tektek incelenmeden olasulmasÅnn bir yolu var mdÅÅr?
SaygÅlar
OKAN
----------------------------------------------------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
_______________________________________________
Linux-programlama mailing list
Linux-programlama_at_liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama
------------------------------------------------------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
------------------------------------------------------------------------------
_______________________________________________
Linux-programlama mailing list
Linux-programlama_at_liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama
_______________________________________________
Linux-programlama mailing list
Linux-programlama_at_liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama
Received on Sat 29 Dec 2007 - 18:46:54 EET