Ahojte potreboval by som pomôct s jedným DB selectom. Možno to niekoho z vás napadne rýchlejšie ako mňa.
Mám 2 tabulky:
TEXTY (ID, TEXT)
HODNOCENI (ID, ID_TEXTU,ZNAMKA) //k jedému id textu je samozrejme viac hodnoteni takze na zoradenie treba spraviť priemer znamok
a potreboval by som vypísať texty podľa obľúbenosti. Ďakujem za každú radu:)
Lukáš
Kacerr poptává: Hledam PHP/JAVA programatora ke spolupraci
Ondrje nabízí: *Kvalitní šablony/úpravy/celé řešení EOBCHOD,PREZENTACE - prestashop,wpress,joomla...
Jakubdolezal poptává: Poptáváme nakódování šablony grafiky webu
SELECT * FROM texty ORDER BY (SELECT AVG(znamka) FROM hodnoceni WHERE id_textu=texty.id GROUP BY id_textu) DESC LIMIT 10
ale je to vykonostne vselijake, ja bych to resil predpocitanym prumerem primo v tabulce textu :) bude to znat hlavne v dobe kdy bude velka spousta textu v db a velka spousta hodnoceni :)
akorat Ti tam chybi nejakej join :-D ale obecne je to spravne ;-)Původně odeslal Aleš Jiříček
Ďakujem pekne za pomoc, s tým prepočítavaním asi máte pravdu, pravdepodobne to tak urobím.
proc? nevis co je to subquery ? JOIN je v tomhle pripade k nicemu, i kdybych chtel vybrat hodnotu AVG hodnoceni tak pouziju subquery
to nevim :-) nikdy v zivote jsem to nepouzival .. je to rychlejsi nez joiny?
ne, pouziva se to v jinych pripadech, zkus mi tohle napsat pres joiny (teoreticky to pujde - ale otazka je jestli jednoduseji a vykonostne vyhodeji) ;)
v jakych napriklad? docela me to zajima.. pracuju jako DB specialista a toto jsem nikdy nepouzival :-) (nemel jsem nikdy potrebu to pouzit)
------
EDIT1:
orientacne takto... jsem v praci tak nemam cas to zkouset
SELECT t.id, t.text, AVG(h.znamka)
FROM texty t
LEFT JOIN hodnoceni h
ON h.text_id = t.id_textu
GROUP BY t.id, t.text
ORDER BY 3 DESC
---------
EDIT2: otazka zni, je rychlejsi join nebo subquery? ted jsem to resil s kolegou (senior Oracle DB specialist) a rikal ze rychlejsi je rozhodne JOIN (az na male vyjimky) ... protoze subquery iteruje vsechny radky a nepouziva INDEXy, coz je neskutecna vyhoda JOINu.. zalezi asi taky na velikosti db.. v male DB ten rozdil nebude az tak rapidni.. ale vzhledem k tomu, ze ja pracuji s miliony radku, tak kdyz jsem se rozhodoval co pouzivat, JOIN pro me byla jasna volba :-)
Naposledy upravil NSBM : 30.08.2011 v 16:53
join
otestoval jsem to na vetsi databazi a dotazy jsou vykonostne velmi podobne, oba stoji ale za starou belu, predpocitany indexovany sloupec bude stokrat lepsi reseni (desetiny sekundy x jednotky milisekund)
tak to je jasny ze predpocitanej sloupec s indexem bude rychlejsi :-D
jj jen jsem chtel rict ze join nic navic oproti subquery nepridal takze neni na 100% duvod ho preferovat (pouzivam oboji v ruznych situacich podle uvazeni)
kazdopadne uz jsem to rikal v prvnim prispevku, tenhle dotaz nelze doporucit v jakekoliv forme, jednou db naroste a stranka zacne padat kvuli ucpani databaze, ja to jeste testoval na nevytizenem serveru, ale verim ze na serveru s vytizenim by ten dotaz byl jeste mnohem horsi
Ales: tak na vetsich projektech je myslim si indexace a prepocitavani samozrejmosti :-) ja volim (preferuji) JOIN z toho duvodu, ze mi prijde zapis o dost prehlednejsi a cistsi .. nedavno jsem videl starou formu zapisu JOINu a malem jsem se poblil :-D
jj ja tu subquery rozhodne obhajovat nebudu, bylo to prvni co me napadlo, protoze mi to prislo jendodussi :)
ale jinak joinuji jak zbesilej, mam tu i projekty kde se prakticky porad joinuje 6,7 tabulke v jedinem dotazu (a pretso jsou dotazy maximalne optimalizovane a probihaji v milisekundach) a nedokazu si predstavit jak jinjak bych ty veci resil, to bych zrejme nemel ani nahodou na jediny dotaz :)
jen 6? :-D hehe.. jen si delam srandu... proti gustu zadny disputat ;-) hlavne ze jsme si to vysvetlili :-) ja join(t)uju furt a jsem spokojenej :-D zatim jsem vyresil vzdycky vse ;-)
---
EDIT1: prave ted ladim select kterej poji 10 tabulek a jeste saha do historickych dat. kde jsou miliony radku.. tak to uz ty milisekundy presahuje (radove nekolik minut) :-D ... proto mam rad delat weby, protoze tam mam vetsinou tak 10-15 tabulek a pohoda :-D ty stovky co mam v praci je silenost :-D
Ďakujem za včetky odpovede, neviete ešte náhodou čo tam mám doplniť aby to nebralo v úvahu texty, kt sú bez hodnotení, pretože pri týchto je priemer nula a keď to dám zoradiť ASC tak sú prvé práve tieto. Niečo ako keď je priemer vačší ako 0
jj mel jsem tu cest s par informacnimi systemy a tam je to silene :) ale zase aspon je to naka challenge, u webu jen malokdy ;)
---------- Příspěvek doplněn 30.08.2011 v 17:19 ----------
WHERE sloupec_s_avg > 0
SELECT t.id, t.text, AVG(h.znamka)
FROM texty t
LEFT JOIN hodnoceni h
ON h.text_id = t.id_textu
GROUP BY t.id, t.text
HAVING AVG(h.znamka) > 0
ORDER BY 3 DESC
ještě lepší by bylo
SELECT t.id, t.text, AVG(h.znamka) FROM texty t, hodnoceni h
WHERE h.text_id = t.id GROUP BY t.id, t.text
ORDER BY 3 DESC
nějak mi uniká v čem je to lepší, vždyť je to přepsání joinu do starého způsobu...
"Lepší" je to v tom, že se eliminuje nevhodně použitý LEFT JOIN, který si vynucuje klauzuli HAVING.
Je tam méně psaní a možná to "ušetří" mikrosekundu.
co jsi to rekl za blbost? having je tam kvuli tomu ze se filtruje podle agregacni funkce AVG() a ne kvuli left joinu :) ten tvuj dotaz by ani nefungoval jak je vyzadovano a ajk funguje spravne dotaz od NSBM
Omyl, HAVING je tam proto, že musí eliminovat zbytečné záznamy vzniklé vinou LEFT JOIN (viz zadání alucky 16:13 s doplněním 17:14).
Zadání vyhovuje prostý JOIN stejně jako uvedený ekvivalent s WHERE. Všechny agregované záznamy pak mají AVG>0 a HAVING je zbytečný.
Funkčně však dávají oba dotazy totožný výsledek.
je to zajimave, protoze jsem si nemyslel ze to tak funguje (no dobre asi nejsem 100% databazar) ale zkusil jsem to a mas pravdu :) otazka je - je to rychlejsi ? (nemam ted cas to testovat)
edit: nakonec jsem to rychle hodil na jendu vetsi db a nemuzu potvrdit ze by v tech dotazech byl rozdil - tvuj dotaz 0,48 skeundy, dotaz s joiny 0,50 sekund (bohuzel ted nemam vetsi db na zatizenem serveru kde by to mohlo byt vic znat)
inner join (join nebo totozne spojeni pres where) by byl vhodnejsi.. uznavam :-)
---------- Příspěvek doplněn 01.09.2011 v 09:52 ----------
alesi inner join je urcite rychlejsi.. zalezi na strukture a logice databaze v jake je postavne.. obecne by melo platit jak pise takatom, ze by se mel pouzit inner join (ktery je nepatrne rychlejsi)
SELECT t.id, t.text, AVG(h.znamka)
FROM hodnoceni h
LEFT JOIN texty t ON t.id_textu = h.text_id
GROUP BY t.id, t.text
ORDER BY 3 DESC
