MySQL: tabellen indelen?

En als je dan een maandtotaal wil, dan moet je dus eerst alle records verzamelen, en daarna de aantallen bij elkaar optellen.
Ik denk dat het makkelijker is om gewoon elke actie afzonderlijk op te slaan, tenzij het echt duizenden acties per dag kunnen worden misschien, dan scheelt het wel in performance denk ik.

het kunnen 0 tot 100 tot 1.000 acties per dag zijn..

het beste kun je dan tijd ook nog toevoegen.

Dan hem je datum en tijd los.. je maakt 1 grote primary key:

lid_id, actie_id, datum, tijd

Vervolgens kun je al het rekenwerk door de database laten doen:

- SELECT COUNT (*) FROM deelname WHERE lid_id = 1 AND datum = 20111202;

De tijd heb je nu geplaatst om twee redenen:
- Alle rows moeten uniek zijn
- Je kunt zelfs zoeken tussen bepaalde tijdstippen.

Marvin, uit je voorbeeld hierboven lijkt het mij alsof je met 2 velden werkt,
1 datum
1 tijd
ik dacht deze gewoon in 1 veld datetime dan kan je toch ook mee doen waar het voor nodig is niet?

Sinds wanneer moeten alle rows uniek zijn! Als de tijd niet belangrijk is hoef je die ook niet op te slaan. (En zeker niet in een aparte kolom.)

In dat geval doe je dus zoiets:
lid_id, actie_id, datum, num

lid_id, actie_id, datum = primary key

INSERT INTO deelname (lid_id, actie_id, datum, num) 1, 2, DATE(), 1 ON DUPLICATE KEY UPDATE num = num + 1

SELECT actie_id,SUM(num) FROM deelname WHERE lid_id = 1 AND datum > (DATE_SUB(CURDATE(), INTERVAL 1 MONTH)) GROUP BY actie_id

SUM is echter wel vaak relatief zwaar, in dit geval dus met 3 acties x 30 dagen 90 rijen. Misschien is dat wel te doen, anders zou je het moeten cachen (dus 1x per .. updaten.) Hangt misschien ook van het aantal bezoekers af.

edit: overigens werk ik liever met Engelse column namen, maar ik dacht ik blijf bij het topic voorbeeld ;)

Nico, je bedoelt met cachen bv elek dag om 12u het totaal in een andere tabel opslaan?

Ja klopt. Maar dat hangt dus ook van het aantal leden, je indeling (hoeveel leden op een pagina), bezoekers (paginaviews), enz af Als je door het "cachen" meer SQL queries hebt dan de bezoekers zullen bekijken dan heeft het natuurlijk geen nut

edit: overigens kan ik wel aardig wat SQL maar performance is niet m'n sterkste punt dus als iemand anders nog suggesties heeft dan ben ik benieuwd :)

Marvin S. heeft het in de tweede reactie al perfect opgelost.

Ik zou niet verder niet weten waarom je deelnames ouder dan 30 dagen zou willen verwijderen. Lijkt me juist handig als je de maanden kan vergelijken.
Daarnaast is dat bij duizend deelnames per dag slechts een paar KB.

Caching is iets waar je je de komende tijd nog niet druk om hoeft te maken.

Sinds wanneer moeten alle rows uniek zijn!

Niets moet paul, maar als je een goede database wilt bouwen, zul je moeten normaliseren.. daar zijn 'standaarden' voor. Simpel voorbeeldje.

10x dezelfde naam plaatsen neemt meer ruimte in als 1 naam met 10 verwijzingen. Of misschien duidelijker als ik zeg:

10.000.000 x "hello world" (110.000.000 characters) in een database neemt veel meer ruimte in beslag als 1x "hello world" (11 characters + 9.999.999 integers).

Rekensom
110.000.000 characters x 8 bit = 880.000.000 bit
(11 characters x 8 bit = 88 bit) + (9.999.999 x 16 bit = 159999984) = 160.000.072 bit

Dan hebben we het volgens mij over 105MB vs 19MB


edit: ik had de datum tijd apart gedaan zodat je zonder verdere (php) functies zowel per datum als tijd het aantal deelnames kunt selecteren.