[php-mysql] Optimale db-structuur voor populaire artikelen

[SYQ]

Ik zit de laatste paar dagen non-stop te werken voor 2 klanten, met een stricte deadline.. dit doe ik naast mijn reguliere werk.. Van s'ochtend 8 tot savonds 11 achter de pc zitten begint blijkbaar te knabbelen aan mijn kunnen, want ik zit nog met 1 klein dillema waar ik 123 niet uit kom

ik moet iets bedenken waarmee ik een view moet maken per dag,week,maand op basis van populariteit. dat laatste is gebaseerd op aantal views per item of het gemiddelde votes per item. het opslaan van aantal views + bijhouden van gemiddelde votes werkt prima.

enig idee hoe ik het best te werk kan gaan??


Werken met de timestamp uit het artikel tabel heeft natuurlijk geen nut, want artikelen die 3 maanden terug zijn geplaatst moeten natuurlijk wel terug kunnen komen in de resultaten van bv:

"populaire artikelen van vandaag" ALS ie vandaag erg vaak geklikt is
of
"populaire artikelen van dit week" ALS ie afgelopen week erg vaak geklikt is
of
"populaire artikelen van deze maand" ALS ie maand erg vaak geklikt is

[wackmaniac]

Ik neem toch aan dat je views en votes ook timestamp'd? Dan zou ik die timestamp gebruiken om de selectie op te maken en niet de timestamp van het artikel.

[SYQ]

wackmaniac schreef op donderdag 05 november 2009 @ 11:47:
Ik neem toch aan dat je views en votes ook timestamp'd? Dan zou ik die timestamp gebruiken om de selectie op te maken en niet de timestamp van het artikel.

nee, op dit moment doe ik dat alleen bij een artikel. maar stel ik ga in de view-tabel de timestamp ook bij houden, dan heb ik alsnog geen goede oplossing toch??

stel het volgende ff voor;
artikelid 500 heeft een total van 2000 views, maar is afgelopen 7 dagen maar 5 keer bekeken
artikelid 900 heeft een total van 80 views, maar is afgelopen 7 dagen 30 keer bekeken

volgens jou methode laat ie dan artikel 500 alsnog boven artikel 900 zien, terwijl dit niet de bedoeling is

[glmona]

SYQ schreef op donderdag 05 november 2009 @ 13:20:
[...]


nee, op dit moment doe ik dat alleen bij een artikel. maar stel ik ga in de view-tabel de timestamp ook bij houden, dan heb ik alsnog geen goede oplossing toch??

stel het volgende ff voor;
artikelid 500 heeft een total van 2000 views, maar is afgelopen 7 dagen maar 5 keer bekeken
artikelid 900 heeft een total van 80 views, maar is afgelopen 7 dagen 30 keer bekeken

volgens jou methode laat ie dan artikel 500 alsnog boven artikel 900 zien, terwijl dit niet de bedoeling is

lijkt me niet, 500 heeft de laatste week minder dan 900 gehit. Die "laatste week" kan je terugvinden voor de getimestampte hits te tellen over de laatste week, dat heeft toch niets met de totaal aantal hits te maken?

[ Voor 3% gewijzigd door glmona op 05-11-2009 15:12 ]

[Cartman!]

Dan zou ik een oplossing kiezen van alle views los opslaan met timestamp en met een cronjob elke x uur berekenen wat de stats van dat product zijn. Dan kun je een veld bijhouden met 'alltime' views, 'lastweek' views en 'lastmonth' views zodat je dit niet per keer hoeft te berekenen.

[Verwijderd]

Cartman! schreef op donderdag 05 november 2009 @ 15:23:
Dan zou ik een oplossing kiezen van alle views los opslaan met timestamp en met een cronjob elke x uur berekenen wat de stats van dat product zijn. Dan kun je een veld bijhouden met 'alltime' views, 'lastweek' views en 'lastmonth' views zodat je dit niet per keer hoeft te berekenen.

Eensch,
Een datetime veld gebruiken is misschien nog makkelijker, omdat je dan makkelijker de check kunt maken.

[SYQ]

Cartman! schreef op donderdag 05 november 2009 @ 15:23:
Dan zou ik een oplossing kiezen van alle views los opslaan met timestamp en met een cronjob elke x uur berekenen wat de stats van dat product zijn. Dan kun je een veld bijhouden met 'alltime' views, 'lastweek' views en 'lastmonth' views zodat je dit niet per keer hoeft te berekenen.

thanks, dit gaat hem dan worden denk ik.. maar als extra ga ik dan in datzelfde cronjob alle data met een timestamp van meer als bv 6maanden legen

[cariolive23]

I.p.v. een cron zou ik eerst eens kijken naar een trigger. Dan ben je altijd up-to-date zonder dat je veel performance inlevert.

Geen idee of dat eenvoudig met MySQL is te regelen, maar het is wel mogelijk.

[Cartman!]

Zo belangrijk om dit continu te updaten lijkt t me niet, het is geen data waarvan je als klant kunt weten dat t achterloopt oid. Als je shop een beetje druk is dan ga je alsnog problemen krijgen met performance lijkt me.

[Tharulerz]

Cartman! schreef op vrijdag 06 november 2009 @ 10:44:
Zo belangrijk om dit continu te updaten lijkt t me niet, het is geen data waarvan je als klant kunt weten dat t achterloopt oid. Als je shop een beetje druk is dan ga je alsnog problemen krijgen met performance lijkt me.

Met een trigger hou je gewoon bij wanneer hij het laatst geupdate is, en ga je hem enkel updaten als dat meer dan X tijd geleden is (en er bezoeker beweging is).

Als je maar 1 bezoeker per dag krijgt kan dit een betere oplossing zijn, alhoewel die 1 cron job het nu ook niet gaat maken

[cariolive23]

Cartman! schreef op vrijdag 06 november 2009 @ 10:44:
Als je shop een beetje druk is dan ga je alsnog problemen krijgen met performance lijkt me.

Klopt, maar dan ben je al snel een paar honderd bezoekers per seconde verder. Zie maar eens een shop te maken die zoveel bezoekers genereert, dit zijn problemen die je heel graag krijgt!