Minimum en maximum aantal rijen retourneren

[radem205]

Hey,

Om bij te houden wie en hoe vaak een profiel bekeken is gebruik ik een aparte tabel om dit bij te houden.

Deze heeft de volgende opmaak:

id	Profielid	Lidid	Datum
1	3	12	2010-02-28
2	3	15	2010-02-28
3	2	16	2010-03-01

Nu wil ik om de populariteit van een lid te bepalen het profiel met de minste bezoekers en het profiel met de meeste bezoekers uit de database halen. En met deze 2 aantallen aan de hand van het bezoekersaantal van een lid de populariteit berekenen (schatting).

Nu heb ik deze SQL, echter doet deze natuurlijk niet wat het moet doen:

SQL:

SELECT 
    profielid,
    COUNT(id) AS aantal
FROM 
    profielbekeken 
GROUP BY
    profielid

Bovenstaande code retourneert wel de correcte aantallen per profiel, alleen moet ik dan met php nog kijken wat het laagste en hoogste aantal is.

Mijn vraag is of dit ook in mysql te regelen is, waardoor er maar 1 rij uit de database komt met het laagste en hoogste bezoekersaantal.

Ik ken het gebruik van MIN() en MAX(), alleen naar mijn weten zijn deze er voor om een minimale waarde in een veld en een maximale in een veld te retourneren en niet de minimale en maximale waarde van een COUNT (overigens ook geprobeerd, maar dit gaf een foutmelding).

[ Voor 13% gewijzigd door radem205 op 06-03-2010 12:33 ]

[Dr. Horrible]

SQL:

SELECT 
    profielid,
    COUNT(id) AS aantal
FROM 
    profielbekeken 
GROUP BY
    profielid
ORDER BY 
    aantal
DESC 
LIMIT 1

Deze query zou als het goed is hem moeten sorteren op aantal, grootste eerst en alleen de eerste teruggeven, wat ook de grootste is.

Als je DESC vervangt voor ASC krijg je de kleinste terug.

[MueR]

Voor zover ik weet zal je dit enkel voor elkaar krijgen met een subquery, en een ranzige ook. Maar ik vraag me af waarom je hiervoor een count gaat doen op je volledige tabel? In dit soort gevallen is het toevoegen van een tellertje ergens in de user tabel veel handiger. Scheelt je een count bij elke keer dat een profiel wordt opgevraagd.

[Gomez12]

Idd, zoals MueR zegt gewoon een counter bij een user neergooien.

Persoonlijk zou ik wel de huidige tabel in stand houden ( counter kan wel eens verkeerd gaan, je wilt misschien later mensen uitsluiten van de count etc) zodat je altijd de counters op user-nivo kan herberekenen mocht het nodig zijn.

Enkel die count die gaat zwaar worden op den duur anders.

Voor je letterlijke vraag moet je gewoon eens kijken eens kijken naar limit en sorteringen, het worden dan enkel wel 2 query's

[radem205]

Het punt is dat de eigenaar wil dat iedereen kan zien wie zijn / haar profiel heeft bekeken. Door deze tabel in stand te houden en ook nog eens een aparte teller te gebruiken in de leden tabel kan het zijn dat deze aantallen op den duur niet meer overeen komen.

Ik denk dat het inderdaad beter is om 2 aparte query's te gebruiken om het minimale en maximale aantal er uit te krijgen.

[McVirusS]

Je kan ook op vast moment script laten draaien die de tellers corrigeert? Lijkt mij qua performance wel mooie winst.

[leuk_he]

Je gaat pas optimaliseren als dat relevant is. tellertje bijhouden ga je pas doen als blijkt dat dit heel vaak bekeken wordt.

Begin gewoon met een subquery gebaseerd op dr horrible (van toepassing zijnde naam....)

[MueR]

Kleine discrepanties kan je in principe zelf corrigeren met een script, maar je zou ook naar beide tabellen de pageview kunnen wegschrijven. Op elke pageview een count moeten doen op die tabel is nou niet zo geweldig. Ik kan me verder ook niet voorstellen dat je alle historische pageviews laat zien aan iedereen, daar heb je vast een limit op zitten.

leuk_he schreef op zaterdag 06 maart 2010 @ 13:34:
Je gaat pas optimaliseren als dat relevant is. tellertje bijhouden ga je pas doen als blijkt dat dit heel vaak bekeken wordt.

Dit is niet optimaliseren, dit is goed ontwerpen vanaf stap 1.

[ Voor 30% gewijzigd door MueR op 06-03-2010 13:35 ]

[Voutloos]

MueR schreef op zaterdag 06 maart 2010 @ 13:35:
...maar je zou ook naar beide tabellen de pageview kunnen wegschrijven. Op elke pageview een count moeten doen op die tabel is nou niet zo geweldig.

Dan ruil je een leesactie per hit in voor een schrijfactie per hit. Dit is een prima voorbeeld van een afgeleid gegeven welke 'eventually consistent' mag zijn. Geen normale sterveling zal de discrepantie merken, laat staan storend vinden.

Je noemt een best leuke optimalisatie, maar daarmee los je het probleem nog niet op. Bovendien wil je in 99/100 gevallen die afgeleide gegevens maar af en toe / asynchroon updaten en is een dergelijke denormalisatie niet een verplicht onderdeel van 'stap 1 van ontwerpen'.

[MueR]

Voutloos schreef op zaterdag 06 maart 2010 @ 14:15:

Ik had ook moeten zeggen "als je perse wilt dat het elke minuut up-to-date is, zou je ook.."