Ranking i sprawa wydajności Opcje

[spit]

Cześć.
Jak już pisałem na forum (może ktoś kojarzy) tworzę nieduży systemik do katalogowania i oceniania moich planszowych gier. Chciałbym, aby była możliwość oceniania ich przez odwiedzających (możliwe, że kiedyś to się rozrośnie (IMG:style_emoticons/default/smile.gif) ). W bazie mam tabelę "ratings", w której trzymam ocenę (pole ratings_rate) i identyfikator gry (ratings_gameid). Wpadłem na pomysł, by pobrać te dane do pliku i dodać im numery, tak:

[SQL] pobierz, plaintext 
	SELECT @i:=@i+1 nr, games_id, ratings_gameid, ratings_rate,
	COUNT(ratings_gameid) AS much,
	SUM(ratings_rate)/COUNT(ratings_gameid) AS all_ratings
 
	FROM games
 
	LEFT JOIN ratings ON games_id = ratings_gameid
 
	GROUP BY games_id
	ORDER BY all_ratings DESC
[SQL] pobierz, plaintext 

Następnie wrzucam wynik do pliku, z niego robię tablicę, przy wywoływaniu listy gier includuje go, i biorę "nr" odpowiadający identyfikatorowi. Teraz pojawia się problem. Jeżeli założymy, że baza gier się rozrośnie (na początek będzie tam zbiór mój i kilku kolegów ze studiów) i wyniesie (luźno liczymy) 500 pozycji, to jak będzie z wydajnością? Chcemy zrobić więcej rankingów, m.in. wg wydawcy i roku wydania, to wszystko to są zapytania, pobierające przecież pięćset rekordów.

Pomyślałem, żeby pobieranie rankingu zrobić w CRONie, raz na dobę. Ale wówczas problemem będzie to, że sortuję wyniki przez średnią arytmetyczną ocen. Mógłbym zamiast umieszczać wyniki w pliku, dawać je do bazy, ale problem główny leży w tym, czy zwykłe konto na serwerze "wydoli" z częstą aktualizacją takich rankingów, powiedzmy... no, szczerze, to przy każdej oddanej ocenie. A może macie jakiś inny sposób na ranking sortowany wg ocen?

Korzystam z ADOdb, gdyby to miało w czymś pomóc.

Ten post edytował spit 19.07.2010, 21:44:43

[thek]

A popatrz, że zapis i odczyt do pliku tablicy za każdym razem to mnóstwo operacji. Masz id gry, ale znajdź ją w pliku (IMG:style_emoticons/default/winksmiley.jpg) Musisz wprowadzić jakiś sensowny sposób prezentacji i zapisu danych w pliku. Zapewne skończy się na XML, który jest po prostu inną formą zapisu danych. I tak będziesz musiał te dane z niego jeszcze jakoś obrabiać, z czasem modyfikować. Baza jest bardziej poręczna niż pisanie tego samemu. Poza tym co to za problem z updatem? Dla mnie to kwestia jednego prostego pomysłu. Podpunkty o jakich mówisz da się zrealizować inteligentnie (IMG:style_emoticons/default/smile.gif) Jak?
1. Musisz zapamiętać jaką pozycję ma obecnie rekord dla jakiego liczysz średnią. To $zapamiętana.
2. Musisz sprawdzić, ile jest rekordów ze średnią większą od Twojej po zmianach. Zapisz ją jako $nowa bo bo zaraz się przyda (IMG:style_emoticons/default/winksmiley.jpg)
3. Jeśli $nowa = $zapamiętana-1 to nie ruszyłeś się w rankingu.
4. Jeśli $nowa > $zapamiętana-1 to spadłeś i musisz wszystkie rekordy z miejscami od $zapamiętana+1 do $nowa zwiększyć o 1 a w obliczanym rekordzie dać pozycję rankingową = $nowa (IMG:style_emoticons/default/smile.gif)
5. Jeśli $nowa < $zapamiętana-1 to podskoczyłeś i musisz wszystkie rekordy z miejscami od $zapamiętana-1 do $nowa zmniejszyć o 1 a w obliczanym rekordzie dać pozycję rankingową = $nowa (IMG:style_emoticons/default/winksmiley.jpg)
Mówisz, że tych UPDATE będzie makabryczna ilość? Wątpię. Nie zmieniasz bowiem za każdym razem wszystkich rekordów tabeli tylko określony zakres wierszy. Po prostu trzeba mieć pomysł jak podejść problem w elegancji sposób, a nie tępym liczeniem za każdym razem wszystkiego jak leci. Zauważ, że podpunkt C, ktorego się najbardziej obawiasz można rozwiązać bardzo elegancko i angażując niemal minimalnie bazę. W określonych przypadkach nawet do UPDATE'u nie dojdzie (zmiana średniej nie wpłynie na pozycję). Na kartce sobie ten mój algorytm sprawdź i sam zobaczysz jak on zmniejsza ilość rekordów zaangażowanych w operacje aktualizacji. W najkorzystniejszym przypadku zmian tylko 2 rekordy się "wymienią" pozycjami.