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
_______________________________________________
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 - 17:30:56 EET