[PHP] Posts tellen

[Verwijderd]

Ik heb een site met een nieuwsscript, een forum, eigen foto upload etc. Nou wil ik graag bij de members het aantal posts tellen. Dus een score bijhouden. Ik kan natuurlijk als iemand een bericht post gewoon +1 doen. Maar dit is niet erg precies, als ik bijvoorbeeld een reactie verwijder.

Daarom doe ik het nu met count ! Hieronder de code.

PHP:

while ($show=mysql_fetch_object($select)) {

$row = mysql_query("SELECT reaction_id FROM news_reactions WHERE user_id='$show->user_id'");   
$aantal1 = mysql_num_rows($row);

$row = mysql_query("SELECT news_id FROM news WHERE user_id='$show->user_id'");   
$aantal2= mysql_num_rows($row);

$aantal= $aantal1+$aantal2;

echo "$show_>username heeft $aantal berichten";
}

Nou vraag ik me af of dit wel een snelle manier is. ALs ik nou 20 members op 1 pagina heb moet hij wel erg vaak deze while loop met het tellen in verschillende tabellen uitvoeren. Is dit een goede manier. Of kan ik het beter op een andere manier doen ?
}

[Verwijderd]

Ooit van COUNT gehoord? En INNER JOIN? En GROUP BY?
Heb je in de gaten dat dit niet een taak is voor PHP maar voor de database (MySQL)?

[Mark Lor]

Daarbij zal het toch handiger zijn, als je forum groter word de postcount bij te houden.
Dit is misschien even meer werk met de delete functie aanpassen enzo maar als er veel posts zijn zal een count slomer zijn.

[Verwijderd]

Hoe doet bijv de PHPBB forum het ? Ook gewoon post +1 doen ?

[Sosabowski]

Count uitvoeren in MySQL is veel netter (en per definitie nauwkeuriger) dan een extra tabel met aantal postings gaan bijhouden.

[Grijze Vos]

Bij een delete doe je toch gewoon weer -1?

Of, zoals ik het doe, als er iets gedelete wordt in het topic, laat ik hem 'voor de zekerheid' even opnieuw een count doen van de posts in dat topic, en die opslaan in een veld van het topic.

Gebruikers posts cache ik niet in mijn forum, omdat ze alleen in het profiel te bezichtigen zijn. (Dat post-geile idee van je postcount onder je username is zo 2001. )

IorGie schreef op 21 september 2004 @ 20:56:
Count uitvoeren in MySQL is veel netter (en per definitie nauwkeuriger) dan een extra tabel met aantal postings gaan bijhouden.

Wie heeft het over een extra tabel? Als je de user-posts wilt cachen sla je hem op als een extra veld bij de user-table. Aangezien je toch al moet joinen met de user-table om de user-name enzo te krijgen..

[ Voor 36% gewijzigd door Grijze Vos op 21-09-2004 20:57 ]

[Verwijderd]

IorGie schreef op 21 september 2004 @ 20:56:
Count uitvoeren in MySQL is veel netter (en per definitie nauwkeuriger) dan een extra tabel met aantal postings gaan bijhouden.

ik dacht altijd dat count niet precies was? (bij veel gevonden records)

[Verwijderd]

IorGie schreef op 21 september 2004 @ 20:56:
Count uitvoeren in MySQL is veel netter (en per definitie nauwkeuriger) dan een extra tabel met aantal postings gaan bijhouden.

Wat is netter? Voor één getal een tabel van 20.000+ records doorlopen of via een index exact één record ophalen? Als het eerste netter is kan je je ook afvragen waarom de bank nog bijvoorbeeld het saldo bijhoudt. Die zouden dan ook beter bij elke saldo aanvraag de afschrijvingen van de stortingen kunnen halen.

Het ligt er gewoon aan in wat voor situatie en omgeving je applicatie zich bevindt. Netter is het wel om een count te doen, maar het is niet per sé beter...

[Verwijderd]

Verwijderd schreef op 21 september 2004 @ 20:57:
[...]

ik dacht altijd dat count niet precies was? (bij veel gevonden records)

Daar heb ik nog nooit van gehoord. Lijkt me héél sterk!

[Verwijderd]

ja, oke, maar ik had het een keer ergens gelezen geloof ik.

[Sosabowski]

Verwijderd schreef op 21 september 2004 @ 21:00:
[...]

Wat is netter? Voor één getal een tabel van 20.000+ records doorlopen of via een index exact één record ophalen? Als het eerste netter is kan je je ook afvragen waarom de bank nog bijvoorbeeld het saldo bijhoudt. Die zouden dan ook beter bij elke saldo aanvraag de afschrijvingen van de stortingen kunnen halen.

Het ligt er gewoon aan in wat voor situatie en omgeving je applicatie zich bevindt. Netter is het wel om een count te doen, maar het is niet per sé beter...

De MySQL functie count() doet iets heel anders dan wat ij hier beschijft. Jij hebt het over x mutaties op een beginsaldo.

Daarnaast denk ik niet dat TS het heeft over > 100.000 records. Op een gegeven moment heb je een degelijk groot aantal dat het interesanter is om wat exra/dubbele data in je database te hebben ten gunste van de server belasting. Maar dat lijkt me hier nog lang niet aan de orde.

Overigen zou ik bij een heel groot aantal records nog steeds een keer in de zoveel tijd die extra kolom bijwerken.

[NMe]

Verwijderd schreef op 21 september 2004 @ 20:57:
ik dacht altijd dat count niet precies was? (bij veel gevonden records)

Wel precies, maar niet snel. Bij een groot forum kun je het dus beter zelf bijhouden. Doen ze hier op GoT ongetwijfeld ook.

IorGie schreef op 21 september 2004 @ 21:14:
Daarnaast denk ik niet dat TS het heeft over > 100.000 records. Op een gegeven moment heb je een degelijk groot aantal dat het interesanter is om wat exra/dubbele data in je database te hebben ten gunste van de server belasting. Maar dat lijkt me hier nog lang niet aan de orde.

Toch moet je hier wel al nu aan denken. Of maak jij altijd programma's en scripts die je na een maand moet aanpassen omdat er dan wat meer gebruikers zijn dan je verwacht had? Altijd scripten met een oog op de toekomst!

[ Voor 51% gewijzigd door NMe op 21-09-2004 21:16 ]

[Sosabowski]

Hier wordt toch echt count() als beste optie aangedragen
[rml][ php/mysql] moeilijke query[/rml]

[Verwijderd]

IorGie schreef op 21 september 2004 @ 21:14:
[...]

De MySQL functie count() doet iets heel anders dan wat ij hier beschijft. Jij hebt het over x mutaties op een beginsaldo.

In principe loopt count() ook alle (met indexes niet) rijen af om te kijken of de rij voldoet aan hetgene wat je wilt tellen. Bij een bank zouden ze om je saldo te verkrijgen ook al je transacties kunnen doorspitten (= alle rijen doorlopen) om te kijken hoeveel er telkens bij of af wordt geschreven en met al die informatie je saldo bepaalt. Dat is het principe wat ik bedoel dat overeenkomt.

Daarnaast denk ik niet dat TS het heeft over > 100.000 records. Op een gegeven moment heb je een degelijk groot aantal dat het interesanter is om wat exra/dubbele data in je database te hebben ten gunste van de server belasting. Maar dat lijkt me hier nog lang niet aan de orde.

Waarom het nu niet implementeren zodat je er niet later weer mee zit? Ik heb het zelf namelijk ook meegemaakt met een klein statistieken-pakketje wat ik had geschreven als onderdeel van een grotere website. Toen er 600 bezoekers op een dag kwamen was het nog goed te doen, maar nu er inmiddels rond de 8.000.000 hits geregistreerd staan vindt de database het minder fijn om een count uit te voeren.

Het ligt dus aan de situatie wat het beste is. Mijn tip voor de topicstarter: "denk goed na over de toekomst en besluit aan de hand daarvan welke variant je kiest." .

[gorgi_19]

IorGie schreef op 21 september 2004 @ 21:23:
Hier wordt toch echt count() als beste optie aangedragen
[rml][ php/mysql] moeilijke query[/rml]

Ja, maar daar was de query eenmalig en performance minder een issue Het is redelijk afhankelijk van de hoeveelheid berichten die in de tabel staan. Ik neem aan dat react niet voor iedere keer dat een pagina opgevraagd wordt, een count uitvoert op de berichtentabel, gegroepeerd op forumId, om het aantal posts per forum te gaan bepalen.

Verder heb je een probleem met het garanderen van het juiste getal, aangezien, afaik, MySQL geen triggers kent. Hierdoor zal je handmatig steeds een update +1 / -1 moeten uitvoeren bij het verwijderen / toevoegen van een record.

Gegevens redunant opslaan is niet per definitie slecht.

[Verwijderd]

Ieder zijn mening. Mijn tip is: schrijf eerst die ene query en gebruik die voorlopig. Probeer te benchmarken hoeveel tijd het je kost per request, kijk wat de server aankan, en als je binnen de grenzen blijft, niets veranderen.

Waarom meteen iets extra's gaan schrijven als je niet weet of de veel eenvoudigere versie ook voldoet? Je verspilt er bijna geen tijd mee.

Alleen als je wéét dat je veel bezoek zult krijgen kun je beter meteen voor de performance optie kiezen.

[Grijze Vos]

Verwijderd schreef op 21 september 2004 @ 21:34:
Ieder zijn mening. Mijn tip is: schrijf eerst die ene query en gebruik die voorlopig. Probeer te benchmarken hoeveel tijd het je kost per request, kijk wat de server aankan, en als je binnen de grenzen blijft, niets veranderen.

Dan moet je al moet een volle database gaan benchmarken (iets wat veel mensen niet doen; met vol bedoel ik echt, een stuk of 10K posts minimaal. )

[qoute]Waarom meteen iets extra's gaan schrijven als je niet weet of de veel eenvoudigere versie ook voldoet? Je verspilt er bijna geen tijd mee.[/quote]Ik vind het echt even eenvoudig hoor. Query maken is zelfs nog eenvoudiger ook.

Alleen als je wéét dat je veel bezoek zult krijgen kun je beter meteen voor de performance optie kiezen.

Het is niet alleen een kwestie van veel bezoek, weinig bezoek levert nog steeds een grote database op na een jaartje. Sorry dat ik het zeg, maar er wordt toch echt teveel gecode met de 'doe het lekker simpel, en kijk het een tijdje aan'-mentaliteit. Iets wat niet echt bevordelijk is voor je product. Je wilt -naar mijn mening- je product onder zoveel mogelijk omstandigheden lekker laten werken, zonder dat het al te veel overhead (extra tijd) kost bij het coden; dan pas kun je spreken van een degelijk gemaakt product.