Hogyan Cache-elnéd?

"Minden eladás után beszúrok egy táblába az eladott termékek azonosítóit egyesével."

Miért? Több millió eladott termék esetén mennyire ront a performancián, ha DB-ből egyesével kell kiszűrnie és rendeznie az adatokat? Hobby projektben nem jönne ki a hiba, de éles környezetben földbe állhat az alkalmazás. :)

"hogy mondjuk ezt 2 óránként frissítse"

Real-time egyszerűbb, mert nem kell ütemezőt beállítani. Ahogy töltöd az adatbázist, azt is olvasod ki a TOP-ok esetén, így indirekt real-time-má válik.

Az SQL-re rá kéne érezni, ha már adatbázisműveleteket szeretnél optimalizálni.

"Szóval, ha mondjuk a termékek táblában egy eladások száma mezőt csinálok, az azért nem fog működni mert az az All-time top selling tudna lenni, de azt semmi nem csökkenti a vásárlás után 2 órával"

Miért kéne csökkenteni bármit is? És miért pont a vásárlás után 2 órával?

Ha minden termékhez van egy eladások száma, azt egy SQL utasítással le tudod kérdezni, és rendezni is. Valahogy így:

SELECT termeknev FROM termek ORDER BY eladasok_szama DESC LIMIT 10

#3 vagyok:

Több lehetésges megközelítés lehetséges:

- Kérdés, hogy a legtöbbet eladottat, hogyan szeretnéd. Lehet, hogy overall (összes lehetségeset) szeretnéd, akkor elegendő egy "eladott" számlálót növelni, hogy mennyit adtál el. Ez nem növel az adatbázis méretén se és a lekérdezett tételeken se.

- Ha elmúlt egy hónapban eladott tételek érdekesek, akkor meghatároznék egy időszakot, hogy napra vagy órára nézzük az egy hónapot? Ha napra nézzük, akkor 2 kulcs határozza meg az eladott tételeket. (Nap, Termék) -> Eladott érték. Majd ezt az "Eladott érték"-et növeled/incrementálod. Így nap*termék rekordod lesz csak. Ami öregebb mint egy hónap azt akár kitörölheted, de WHERE-el szűrheted is. Nyilván INDEX-nek be kell állítani a NAP-ot és a TERMÉK-et is, hogy gyorsabb legyen.

- Vagy alapvetően nem relációs adatbázist használsz erre a célra, ha ilyen metrikákat akarsz mérni, hanem mondjuk InfluxDB-t, ami idő-soros adatbázis.