Jeg ville bare oprette en post for hver gentagelse af begivenheden, ud til en eller anden horisont. Det betyder dog, at du skal bruge en anden tabel, som du kan bruge til at fremskrive datoerne, hvis de scanner forbi din horisontdato. Dvs., du skal bruge en hændelsestabel, der indeholder én post for hver forekomst af en gentagen hændelse (1. jan., 8. jan., 15. jan. ... til og med december), og en tabel med hver post, der er tilgængelig for fremtidige år (start dato:1. januar; gentag:7; til og med:2011), så du i starten af 2012 (eller så snart brugeren anmoder om en visning af en 2012+ måned) kan generere fremtidige begivenheder.
Dette har to store ulemper:
- Din database har data for et helt år. Men hvis tilføjelse af et helt års data ødelægger din ydeevne, er dit system sandsynligvis understrøm. (Det lader til at være et krav, at en kalenderapp skal kunne håndtere mange års datoer)
- I slutningen af begivenhedshorisonten skal du generere fremtidige datoer for tilbagevendende begivenheder.
Fordelene (IMO), der opvejer ulemperne:
- Nemmere matematik ved visning af kalenderen. Ved at bruge Tims metode ovenfor, hvis brugeren indlæser 18. december 2011, hvordan vil du så beregne hvilke tilbagevendende begivenheder der skal placeres på den dag? Du vil blive tvunget til at gå igennem HVER tilbagevendende begivenhed, hver gang du viser en dato. Afvejningen er ulempe #1, som jeg mener er den bedre løsning end at skulle lave disse beregninger om.
- Du kan redigere specifikke forekomster af en begivenhed. Ved at bruge Tims metode, hvis et møde fandt sted på en helligdag, og brugeren ændrede det til den foregående dag, hvordan ville du så overhovedet gøre det? Ved at bruge metoden med én indtastning pr. begivenhed, der er beskrevet her, kan du bare ændre denne registrering for begivenheden og nemt flytte enkelte begivenheder rundt i kalenderen.