[DB] Uitrekenen of waarde opslaan?

[Verwijderd]

Stel je hebt een forum gemaakt, dan wil je weten het aantal topic dat elk forum heeft, of het aantal posts van een gebruiker.

Nu zijn er voor zover ik wete twee mogelijkheden om dat te doen.

1 - COUNT() gewoon alles waar de forumid/gebruikerid een bepaalde waarde heeft
2 - Bij elke nieuwe post of topic doe je +1 bij het aantal_getal veld. (maar dan moet je met locks werken zodat er niet twee tegelijk updates worden uitgevoerd?)

Ik doe het zelf door het uit te rekenen met COUNT maar is dat niet een gigantishce belasting voor de database server?

Ik zie de tweede methode bij de grotere commerciele/gratis forums.. maar welke methode is nou beter?

[Verwijderd]

Ik zelf gebruik ook altijd count. Maar ik weet niet zeker of dat beter is.
Zou het ook wel is willen weten.

[Cavorka]

Verwijderd schreef op zaterdag 29 januari 2005 @ 12:25:
Ik zie de tweede methode bij de grotere commerciele/gratis forums.. maar welke methode is nou beter?

Is dit een retorische vraag?

Natuurlijk is die tweede methode beter. De eerste methode kan gewoon een server killer worden als je die elke seconde een paar keer gaat uitvoeren. En vooral die paar extra opslag-bytes moeten er toch wel afkunnen lijkt me?

Misschien een keer per dag die COUNT() uitvoeren (om je waardes te dubbelchecken), maar ik zou de UPDATE + 1 gebruiken.

Als je een kleine forumpje maakt, dan maakt het niet zoveel uit natuurlijk, maar ik vind de 2e methode ook gewoon netter, ondanks dat het misschien overbodige (dubbele) data is.

[ Voor 15% gewijzigd door Cavorka op 29-01-2005 12:31 ]

[PrisonerOfPain]

Verwijderd schreef op zaterdag 29 januari 2005 @ 12:28:
Ik zelf gebruik ook altijd count. Maar ik weet niet zeker of dat beter is.
Zou het ook wel is willen weten.

Probeer dat nou eens met een post of 500.000... Zeker weten dat een SELECT op één row een stuk sneller is als een COUNT welke je volledige table afloopt.

[Verwijderd]

PrisonerOfPain schreef op zaterdag 29 januari 2005 @ 12:37:
[...]

Probeer dat nou eens met een post of 500.000... Zeker weten dat een SELECT op één row een stuk sneller is als een COUNT welke je volledige table afloopt.

Daar heb je gelijk in, maar ik bij kleine projecten waar ik momenteel mee bezig ben zal count denk niet zoveel schelen. Het is maar net hoe groot je project is. Bij een klein project vind ik een extra veld aanmaken nogal overdreven. Terwijl een groot project het echt nodig heeft.

[Killemov]

De meeste DB-engines gaan sowieso niet je hele tabel aflopen hoor (erm ... MySQL geloof ik WEL), die hebben in de query-analyse fase allang door dat het om de rowcount van de volledige tabel gaat. Dan moet je natuurlijk geen WHERE clause gebruiken natuurlijk!

[Cavorka]

Killemov schreef op zaterdag 29 januari 2005 @ 12:50:
De meeste DB-engines gaan sowieso niet je hele tabel aflopen hoor (erm ... MySQL geloof ik WEL), die hebben in de query-analyse fase allang door dat het om de rowcount van de volledige tabel gaat. Dan moet je natuurlijk geen WHERE clause gebruiken natuurlijk!

Hier staan wel erg veel condities in waaraan je moet voldoen, zodat je COUNT() kan gebruiken.

En wat is 'meeste'? Welke wel? Welke niet?

[ Voor 6% gewijzigd door Cavorka op 29-01-2005 12:53 ]

[Kees]

Geen count gebruiken.
Als ik voor tweakers de exacte count van een gebruiker wil weten is hij daar al snel 5 minuten mee bezig (ok, bijna 20M posts en innodb)

[NMe]

Killemov schreef op zaterdag 29 januari 2005 @ 12:50:
De meeste DB-engines gaan sowieso niet je hele tabel aflopen hoor (erm ... MySQL geloof ik WEL), die hebben in de query-analyse fase allang door dat het om de rowcount van de volledige tabel gaat. Dan moet je natuurlijk geen WHERE clause gebruiken natuurlijk!

Het is idd zo dat sommige database servers per tabel wat gegevens opslaan, zoals de rowcount. Maar als je het aantal posts van een bepaalde gebruiker wil weten zonder WHERE in je query, dan kom je niet ver. Of wou je één tabel per user gaan aanmaken? Economisch!

Wat beter is, dat is iets wat je zelf moet bepalen. Wanneer het vermijden van redundantie betekent dat de bereikbaarheid en continuïteit van je server in het geding komt, dan mag je best een beetje denormaliseren, en daarmee dus berekenbare gegevens toch opslaan. Wanneer je verwacht dat je forum erg groot zal worden, of in ieder geval veel posts zal hebben gedurende de tijd dat je het online hebt staan, dan is denormaliseren zeker de beste optie. Is het een forum waar je slechts tijdelijk gebruik van wil maken (voor een projectgroep ofzo) en verwacht je weinig posts (<10.000 ofzo), dan kun je ook wel met COUNT werken.

[Verwijderd]

Zuiver principieel bekeken is methode 1 het beste. In een genormaliseerde database hoor je geen waardes op te slaan die af te leiden/te bereken zijn aan de hand van andere waardes.

In de praktijk echter kan een count query een belasting zijn, of je DB er nu voor optimaliseert of niet. Het lijkt mij bv. stug dat GoT een count gebruikt voor de aantallen postings in een forum/draad. Dan zou ze handel waarsch. binnen no-time plat gaan.

Als performance een issue is, by all means, verzin iets zodanig dat je geen count hoeft te gebruiken. Als performance niet zo'n issue is, houdt je aan de regels voor het normaliseren en gebruik count. Zo simpel is het imo

[Jacco Swart]

Misschien is het even makkelijk om wat theorie te bekijken over normaliseren en kijk dan eens naar de 4e normaalvorm.

(Redundancy is toegestaan (Dubbel opslaan van data voor snelheid)

[Verwijderd]

Mijn persoonlijke keus is ook om COUNT te gebruiken, maar eigenlijk alleen maar omdat ik daar vertrouwd mee ben.

Want als je de waarde uit gaat lezen, dan is dta geen probleem maar wat als je moet updaten? en als er twee users tegelijk die waarde proberen te updaten?
Moet je dan met lock tables werken? en dat is toch helemaal niet snel? (mysql)

[NMe]

Verwijderd schreef op zaterdag 29 januari 2005 @ 15:48:
Mijn persoonlijke keus is ook om COUNT te gebruiken, maar eigenlijk alleen maar omdat ik daar vertrouwd mee ben.

Want als je de waarde uit gaat lezen, dan is dta geen probleem maar wat als je moet updaten?

code:

UPDATE tabel SET veld = veld + 1 WHERE anderveld = 12

en als er twee users tegelijk die waarde proberen te updaten?

Een gebruiker mag normaal toch niet zijn account delen met iemand? Verder moet het wel heel erg toevallig zo uitkomen dat ze precies tegelijk komen. En dan nog, met bovenstaande query is dat geen issue.

Moet je dan met lock tables werken? en dat is toch helemaal niet snel? (mysql)

Hoeft niet.