JOIN vagy SUBSELECT

kedves mindenki!

regota foglalkoztat a dolog, hogy hogyan irjak meg egy lekerdezest ugy, hogy optimalis, eroforrasgazdasagos, es gyors legyen, persze megfelelo indexekkel tamogatva.
alapjaban veve en a subselectek hive vagyok, a joinokat nem kedvelem kulonosebben.

egy logikat kovetve miszerint: van 3 1000 soros tablam, joinolom id-kkel,
es lesz egy 3000 soros "tablam", amit aztan whereben szurok.

de ha fogom az eredeti 1000 sorost, es subselectben kerdezem le a szukseges adatokat.

tapasztalataim alapjan sokkal gyorsabb az utobbi logika.

nektek mik a tapasztalataitok?

Lekérdezése válogatja, alapesetben ha az első subselect id-kal tér vissza és id in (subselect) -tel szürsz akkor amig 10-20 eredményed van a subselectből tényleg gyorsabb, kősőbb viszont, ha már 100-120 sort kapsz a subselectből akkor nem biztos. Igazából meg kell irni a query -t mind a két féle módon és megnézni. Régebben én is alapvetően join ellenes voltam, de vannak esetek amikor minden más megoldás sokkal lassabb.

Kedves mza8202!

Logikailag a SUBSELECT gyorsabb, azonban tapasztalataim szereint (főleg MySQL) a JOIN kiszámíthatóbb és stabilabb. Ezt úgy értem, hogy kis adatmennyiség esetén a SUBSELECT tényleg verheti sebességben a JOIN-t, azonban az adatmennyiség növekedésével a lekérdezés ideje nem arányosan növekszik.

Ha már itt tartunk, azt is érdemes megfontolni, hogy ugyan azt az eredményt nem érjük -e el gyorsabban, ha több külön lekérdezés csinálunk és az eredményeket progam szinten összesítjük. Ebben az esetben ugyanis használhatunk cache-t is a további gyorsításra, ha megengedhető, hogy egy kis szinkronizációs eltolódás.

Üdvözlettel
kjaron

Nálunk a cégnél MSSQL 2005 szerveren fut egy SAP és én úgy vettem észre, hogy a join egyrészt áttekinthetőbb másrészt gyorsabb, mint egy subselect. Azt hozzáteszem, hogy ez 5000-10000-es rekordmennyiségnél volt és nem vagyok profi adatbázis-adminisztrátor, ezek csak tapasztalatok (másodpercekben)

Igazából ha tudod, hogy mit akarsz és le is tudod írni, akkor már tudod a legjobb megoldást...

Én mindenhol a külön külön lekérdezés híve vagyok. Mégpedig azért, mert tökéletesen átlátható.

Vegyük például azt, hogy van egy user_id és user_email egy táblán. user_id user_nev külön táblában van. Megadják a user_mail -t... lekérdezem a user_email -t és a hozzá lévő user_id -t utána lekérdezem a user_nev -t ahol user_id = $user_id...

Igazság szerint párszor mertem joint használni, de mikor majd összefosta az első szerverem magát inkább hagytam az egészet... nekem még mindig ez a leggyorsabb megoldás, vagy már stabilabb lett a join, esetleg subselect? (2002 óta nem használom ezeket)

Cheers és finoman a FLAME kkel :)

@artidas
az amit te irsz elég terhelő megoldás a server számára. a minden külön táblából külön lekérdezéssel kérdezel le olyan adatokat amit egybe tudnál lekérdezni az óriási hiba. valószinű hogy a join-od rosszul volt megírva eseteg nem használtál index-et.

Idézet:

---

Geri eredeti hozzászólása

@artidas
az amit te irsz elég terhelő megoldás a server számára. a minden külön táblából külön lekérdezéssel kérdezel le olyan adatokat amit egybe tudnál lekérdezni az óriási hiba. valószinű hogy a join-od rosszul volt megírva eseteg nem használtál index-et.

---

Lehet igazad van (sőt biztos)... nemsokára kipróbálom és átírok egy két dolgot :)

Kösz Geri,

Cheers

Idézet:

---

ARTidas eredeti hozzászólása

Lehet igazad van (sőt biztos)... nemsokára kipróbálom és átírok egy két dolgot :)

Kösz Geri,

Cheers

---

Én is úgy tudom, hogy egy SQL query mindig gyorsabb, mint egy (akár) PHP kód. A join-t is kitalálták valamiért. Ahogy mondani szokás, általában az user a ludas a felmerülő hibák miatt, nem pedig a program készítője és ez itt is igaz. (ezt nem flame-nak szántam).

Én a join-ra (persze megfelelő indexeléssel) szavazok kivéve amikor csak subselect-tel végrehajtható a lekérés. Ha túl sokáig tart a lekérés (többmilliós adatbázisok esetén), akkor néhány temporary table is gyorsíthat a dolgokon (MSSQL, de lehet hogy az újabb MYSQL is kezel már ilyeneket).