Ik zou gewoon een vermelding maken voor elke herhaling van de gebeurtenis, tot aan een bepaalde horizon. Het betekent echter dat u een andere tabel nodig heeft die u kunt gebruiken om de datums te projecteren als ze voorbij uw horizondatum komen. Dat wil zeggen, u hebt een gebeurtenissentabel nodig die één record bevat voor elk optreden van een herhaalde gebeurtenis (1 januari, 8 januari, 15 januari, ... tot december), en een tabel met elk record dat beschikbaar is om toekomstige jaren te zaaien (start datum:1 jan; herhaling:7; t/m:2011) zodat u begin 2012 (of zodra de gebruiker een weergave van een 2012+ maand aanvraagt) de toekomstige gebeurtenissen kunt genereren.
Dit heeft twee grote nadelen:
- Je database bevat gegevens voor een heel jaar. Als het toevoegen van een heel jaar aan gegevens uw prestaties echter verpest, heeft uw systeem waarschijnlijk te weinig vermogen. (Het lijkt een vereiste dat een kalender-app vele jaren aan datums aankan)
- Aan het einde van de gebeurtenishorizon moet u de toekomstige datums voor terugkerende gebeurtenissen genereren.
De voordelen (IMO) die opwegen tegen de nadelen:
- Gemakkelijker rekenen bij het weergeven van de kalender. Met behulp van de methode van Tim hierboven, als de gebruiker 18 december 2011 laadt, hoe gaat u dan berekenen welke terugkerende gebeurtenissen op die dag moeten worden geplaatst? Elke keer dat u een datum weergeeft, moet u ELKE terugkerende gebeurtenis doorlopen. De afweging is nadeel #1, wat volgens mij de betere oplossing is dan deze berekeningen opnieuw te moeten uitvoeren.
- Je kunt specifieke instanties van een gebeurtenis bewerken. Met behulp van de methode van Tim, als een vergadering plaatsvond op een feestdag en de gebruiker veranderde deze naar de vorige dag, hoe zou je dat dan doen? Met behulp van de hier beschreven methode met één invoer per gebeurtenis, kunt u dat record voor de gebeurtenis wijzigen, waarbij u eenvoudig afzonderlijke gebeurtenissen in de kalender kunt verplaatsen.