[php/mysql] opslaan in database of berekenen?

[Roa]

Ey mensen,

Ik ben al een tijdje bezig met een forum, en heb me deze vraag al meerdere malen gesteld.

Moet ik het aantal posts in een topic, of in een forum, nou opslaan in de database (dus bij de topicsgegevens) of moet ik em berekenen (een num_rows dus).

Tot nu toe heb ik het altijd opgeslagen. Dus bij iedere nieuwe post update ik het veld 'topic_replies' met +1. Dit gebeurd bij de topics, en bij de subfora, naja, je kan het je wel voorstellen.

Het zelfde met de laatste post in een bepaald topic of fora. Je kan op de index meteen zien we het laatste gereageerd heeft en door op de link te klikken meteen naar de betreffende post gaan. Ook dit sla ik op door een een id op te slaan in 'last_post_id'.

Tot nu toe leek me dit altijd handiger, omdat het aardig wat query's kan schelen. Maar nu ben ik bezig met het delete script en ik begin nu in te zien dat dit script wel zeer complex gaat worden, omdat er van alles uitgezocht en geupdate moet worden. Is de post die ik verwijder de laatste post in een forum of topic (of beide)? Zoja, wat is dan de volgende laatste post.

Hetzelfde met het update van de cijfers voor replies e.d.. Ik begin nu te neigen naar een query die gewoon even telt hoeveel posts er zijn. Dan hoef ik dit soort complexe dingen niet te gaan scripten. Ook omdat er op een bepaald moment 5 dingen moeten worden geupdate om 1 post te verwijderen. Je kan je voorstellen dat als er een topic verwijderd wordt, er bij iedere post een controle moet komen om te kijken hoe die post andere cijfers beïnvloed.

Het is nu dus kiezen, alles opgeslagen houden?
Of het aantal query's op het forum verdubbelen?

Als ik bij ieder topic het aantal posts moet tellen, betekend dat een extra query per topic. Als je 5 topics hebt, is dit geen ramp, maar wat als er 20 topics zijn? enzovoorts.

Hoe hebben anderen dit dus opgelost, en zit ik misschien fout met mijn tel manier, is er een manier om het aantal query's te beperken, of moet ik toch maar alles opslaan.

Ik hoop dat u mij kunt helpen, want ik weet het even niet meer.

(ojah, ik drukte per ongeluk op tab en enter toen ik de titel wilde wijzigen, dus die is nu verneukt, zou een modje die even kunnen verbeteren? alvast bedankt )

[ Voor 14% gewijzigd door Roa op 05-04-2004 23:35 ]

[Priet]

Les 1 bij databases: zorgen dat er geen redundante gegevens in je database staan.

Het aantal posts staat al in je database. Indirect, dat wel, maar het staat er wel in! Dus waarom zou je het nog een keer opslaan? Daar zijn juist queries voor uitgevonden

[Brakkie]

Toch is het erg gebruikelijk om bij forumsoftware die totalen toch ook op te slaan. Dit gebeurd vooral om performance redenen.

Als je voor de index pagina van een board van 20 fora de count van het aantal topics en posts moet gaan ophalen kan je wel nagaan dat dat een zware query is.

[ Voor 39% gewijzigd door Brakkie op 05-04-2004 23:50 ]

[koli-man]

Tja, normaal gesproken bij een forum laat je toch niet alle fora zien, alleen de 20 recentste f zo dus die count query die je erop los laat zal echt niet veel aan de performance uitmaken. Dus dan zou ik in dit geval je een veldje ==ruimte besparen en de moeite doen om die count erin te gooien.

[ Voor 6% gewijzigd door koli-man op 05-04-2004 23:48 ]

[ripexx]

Priet schreef op 05 april 2004 @ 23:38:
Les 1 bij databases: zorgen dat er geen redundante gegevens in je database staan.

Het aantal posts staat al in je database. Indirect, dat wel, maar het staat er wel in! Dus waarom zou je het nog een keer opslaan? Daar zijn juist queries voor uitgevonden

Les twee is preformance!

Over dit onderwerp zijn er al genoeg discussies geweest. Als je het normalisatie proces zou volgen dan kom je tot de conclusie dat de verschillende totale geen eigenveld zouden mogen hebben. Maar als je een forum heb met veel, heel veel berichten is wordt zo'n query behoorlijk zwaar. Daarnaast neemt een integer nou ook weer niet zoveel ruimte in.

[gorgi_19]

Priet schreef op 05 april 2004 @ 23:38:
Les 1 bij databases: zorgen dat er geen redundante gegevens in je database staan.

Het aantal posts staat al in je database. Indirect, dat wel, maar het staat er wel in! Dus waarom zou je het nog een keer opslaan? Daar zijn juist queries voor uitgevonden

Probeer je eens voor te stellen als dit forum voor iedere user het aantal posts steeds moet berekenen.. Mag je wel een extra database servertje neerzetten...

[Janoz]

Het tellen doe je sowieso niet met num_rows, maar met een count in je query. Dat is vele malen sneller omdat deze alleen de gegevens bepaald en onthoud die je nodig hebt.

In principe zou ik eerst aanraden om het gewoon met een count query te doen. Bij het gebruik van een goed RDBMS worden queries die vaak worden uitgevoerd gewoon gechached. Als er echt performance problemen beginnen op te treden kun je alsnog het veld toevoegen. Bij een goed ontwerp hoeft dit helemaal geen probleem te zijn.


@ripexx : Het gaat niet om de ruimte die de integer inneemt, maar of je kunt garanderen dat hierin de juiste waarde zit .

[PhoeniX-]

Priet schreef op 05 april 2004 @ 23:38:
Les 1 bij databases: zorgen dat er geen redundante gegevens in je database staan.

Het aantal posts staat al in je database. Indirect, dat wel, maar het staat er wel in! Dus waarom zou je het nog een keer opslaan? Daar zijn juist queries voor uitgevonden

Je hebt helemaal gelijk, alleen als je aan performance gaat denken, dan moet je meestal een of meerdere stappen terug doen in je normalisatie proces. Performance-wise is het denk ik makkelijker/beter om direct deze totalen op te hogen (dat hoeft maar 1x te gebeuren, het berekenen ervan zou per pagehit moeten gebeuren).

[Pathogen]

tsja, opslaan per post of berekenen per pagehit...
zou je eigenlijk moeten benchen

Reken op 5-10 hits voor 1 post denk ik...

mijn gok is dat het opslaan sneller gaat

[ripexx]

Janoz schreef op 06 april 2004 @ 09:58:
@ripexx : Het gaat niet om de ruimte die de integer inneemt, maar of je kunt garanderen dat hierin de juiste waarde zit .

Ik ken het probleem en ben er zelf al een aantal keren tegen aangelopen. Zeker bij een goede RDBMS is het goed mogelijk maar mysql < 4 heeft nog genoeg problemen. Mede door het niet aanwezig zijn van FK enz.

Als je het goed volgens de regels zou doen dan moet je het gewoon doen met een count.

[Janoz]

PhoeniX- schreef op 06 april 2004 @ 09:58:
[...]

Je hebt helemaal gelijk, alleen als je aan performance gaat denken, dan moet je meestal een of meerdere stappen terug doen in je normalisatie proces. Performance-wise is het denk ik makkelijker/beter om direct deze totalen op te hogen (dat hoeft maar 1x te gebeuren, het berekenen ervan zou per pagehit moeten gebeuren).

Veel mensen denken echter al veel te snel aan performance en kijken naar de verkeerde dingen. Begin met de zwaktste schakels. De bottlenecks van je applicatie. Als een postcount opslaan een winst van 5 ms per page hit oplevert, maar je template parser 3sec bezig is dan kun je je tijd veel beter besteden aan het optimalizeren van de template engine.

[Janoz]

Thrackan schreef op 06 april 2004 @ 10:18:
tsja, opslaan per post of berekenen per pagehit...
zou je eigenlijk moeten benchen

Reken op 5-10 hits voor 1 post denk ik...

mijn gok is dat het opslaan sneller gaat

Met dit aantal zou het zeker nog spannend worden. Een update is performance wise duurder dan een select ..

[PhoeniX-]

Dat zijn inderdaad afwegingen die je moet maken Janoz (-:

Hangt natuurlijk volledig af van de drukte van je site/forum. Als je bijvoorbeeld 10 hits per dag hebt zou ik lekker alles met count() berekenen

edit:

Zag net pas deze post:
[quote]Reken op 5-10 hits voor 1 post denk ik...[/quote]
Probeer 't eens zou ik zeggen (-: (wat sneller is)

[ Voor 30% gewijzigd door PhoeniX- op 06-04-2004 11:09 ]

[Pathogen]

Janoz schreef op 06 april 2004 @ 11:06:
[...]


Met dit aantal zou het zeker nog spannend worden. Een update is performance wise duurder dan een select ..

Ja ach ik heb niet veel verstand van benchmarks van dit soort acties... Maar denk ik gooi mijn idee er ff uit

[PhoeniX-]

idd Thrackan

Je kan 't ook weer zo bekijken:

Een update kost meer tijd dan een select, maar een update hoeft waarschijnlijk minder vaak uitgevoerd te worden dan een select ..

[Pathogen]

Kortom:

-Zoek de verhouding tussen pagehits en posts.
-Bench berekenen en opslaan.
-reken de tijd om met je gevonden ph/post verhouding.

en voila, je oplossing is daar...

en als het zo goed als gelijk is is het enige wat ik nog kan zeggen:

Een database entry kost ruimte ( en een bereken functie ook)

Waah plz post wat je als oplossing vind want ik word er nou zelf gek van

[NMe]

Thrackan schreef op 06 april 2004 @ 11:44:
Waah plz post wat je als oplossing vind want ik word er nou zelf gek van

Er is geen algemene "oplossing". Het gaat erom dat je iets krijgt wat goed en snel werkt waarvoor het ontworpen is. Zoals al eerder gezegd in dit topic is het belangrijk te kijken naar wat je doet voordat je allerlei gekke dingen gaat doen om de performance beter te krijgen. Een forum dat 2 hits per dag krijgt optimaliseren op dit soort dingen heeft natuurlijk geen nut...

[Cuball]

Janoz schreef op 06 april 2004 @ 11:04:
[...]

Veel mensen denken echter al veel te snel aan performance en kijken naar de verkeerde dingen. Begin met de zwaktste schakels. De bottlenecks van je applicatie. Als een postcount opslaan een winst van 5 ms per page hit oplevert, maar je template parser 3sec bezig is dan kun je je tijd veel beter besteden aan het optimalizeren van de template engine.

wel opletten dat die 3sec constant blijven bij je template engine, maar die 5ms niet meer naargelang het aanal postcounts, dus na verloop van tijd zou die 5ms de 3sec van je engine kunnen inlopen.

[Roa]

Sorry voor m'n late reactie, ik was m'n pc ff aan het uit elkaar halen voor een kleine ingreep in m'n case. (ik heb m'n floppydrive gesloopt..arm ding...kan iemand me vertellen of er overal van die pinnetjes moeten zitten, er mist er namelijk 1 bij mij, denk dat dat de oorzaak is )

Anyway, ik heb nog niet echt besloten wat ik nou ga doen. Ik weet niet hoe druk het gaat worden. Ik kom binnenkort wel met wat ik doe, in ieder geval is er, zoals ik dacht, geen kant en klare oplossing. De meningen zijn hier ook verdeeld..tja...

Alvast bedankt in ieder geval, ik ga morgen wel beetje testen.

[bigtree]

Ik zou voor een extra veld gaan. Dan is je applicatie meteen schaalbaar. Het is irritant om dat later nog om te moeten bouwen. Door er nu meteen rekening mee te houden scheelt dat straks meer werk.

[Grijze Vos]

Ik heb bij mijn forumpje ook ze wel opgeslagen, het scheelt wel redelijk wat hoor (in MySQL dan.) Zeker nu mn table in de 10.000 posts begint te lopen.

De makkelijkste manier om te zorgen dat het update strak verloopt is bij deletes (van posts of topics) en moves van complete topics en wat niet gewoon 2 php functies bouwen. refresh_board($id) en refresh_topic($id). Die twee laat je een count doen, en laat je aan de hand daarvan die waarde updaten. Bij een move moet je overigens eraan denken dat je 2 boards moet updaten.

[ Voor 3% gewijzigd door Grijze Vos op 07-04-2004 00:18 ]

[Speedener]

Grijze Vos schreef op 07 april 2004 @ 00:17:
Ik heb bij mijn forumpje ook ze wel opgeslagen, het scheelt wel redelijk wat hoor (in MySQL dan.) Zeker nu mn table in de 10.000 posts begint te lopen.

De makkelijkste manier om te zorgen dat het update strak verloopt is bij deletes (van posts of topics) en moves van complete topics en wat niet gewoon 2 php functies bouwen. refresh_board($id) en refresh_topic($id). Die twee laat je een count doen, en laat je aan de hand daarvan die waarde updaten. Bij een move moet je overigens eraan denken dat je 2 boards moet updaten.

IMHO is het helemaal niet boeiend of er 3456 topics in een forum staan of 3455.

Je moved een keer daar heen, en dan een ander topic weer terug dus het blijft allemaal wel redelijk in orde enzo.

Wat wel irri wordt is de last-post omdat die evt verwijderd zou kunnen worden ofzo.

[Roa]

Ohk, ik ben eruit.

Ik heb toch besloten het opgeslagen te houden, maar om te zorgen dat de gegevens kloppen maak ik een functie die na verwijderen van posts opnieuw gaat berekenen hoeveel posts erin staan en dergelijke. Zo houd ik m'n script netjes op orde, en heb ik toch de zekerheid van juiste gegevens. Allemaal bedankt in ieder geval!

[Roa]

Ik vat er de ballen van, ik heb devolgende query:

code:

UPDATE forum_forums SET forum_posts = '101' AND forum_last_post_id = '131' WHERE forum_id = '0'

En hij geeft 0 resultaten zeg maar... Ik snap echt niet wat hier aan de hand is? Waarom doet hij het niet Er is toch echt een rij die forum_id heet in de tabel forum_forums.


*update*

damn, wat een eikel ben ik, me een half uur blind staren op die query voordat ik me bedenk dat een update niet met AND werkt

*second update*

Goed, ik ben nu klaar, ik heb een functie gebouwd die het topic/forum naloopt en de waardes update. Ook heb ik meteen maar een sync functie gemaakt: via het CMS kan ik het forum synchroniseren met de database, nu nog leuk, als het ooit 10.000 topics zijn misschien wat minder

[ Voor 47% gewijzigd door Roa op 12-04-2004 02:17 ]