Ich würde einfach einen Eintrag für jede Wiederholung des Ereignisses bis zu einem gewissen Horizont erstellen. Dies bedeutet jedoch, dass Sie eine weitere Tabelle benötigen, mit der Sie die Daten projizieren können, wenn sie über Ihr Horizontdatum hinausgehen. Das heißt, Sie benötigen eine Ereignistabelle, die einen Datensatz für jedes Auftreten eines wiederholten Ereignisses enthält (1. Januar, 8. Januar, 15. Januar, ... bis Dezember), und eine Tabelle mit jedem Datensatz, der für zukünftige Jahre verfügbar ist (Start Datum:1. Januar; Wiederholung:7; bis:2011), damit Sie Anfang 2012 (oder sobald der Benutzer eine Ansicht eines Monats ab 2012 anfordert) zukünftige Ereignisse generieren können.
Das hat zwei große Nachteile:
- Ihre Datenbank enthält Daten für ein ganzes Jahr. Wenn jedoch das Hinzufügen von Daten für ein ganzes Jahr Ihre Leistung ruiniert, ist Ihr System wahrscheinlich zu schwach. (Es scheint eine Anforderung zu sein, dass eine Kalender-App Daten von vielen Jahren verarbeiten kann)
- Am Ende des Ereignishorizonts müssen Sie die zukünftigen Daten für wiederkehrende Ereignisse generieren.
Die Vorteile (IMO), die die Nachteile überwiegen:
- Einfachere Mathematik beim Anzeigen des Kalenders. Wenn der Benutzer den 18. Dezember 2011 lädt, wie werden Sie mit Tims obiger Methode berechnen, welche wiederkehrenden Ereignisse an diesem Tag platziert werden sollen? Sie müssen jedes Mal, wenn Sie ein Datum anzeigen, JEDES wiederkehrende Ereignis durchlaufen. Der Kompromiss ist Nachteil Nr. 1, was meiner Meinung nach die bessere Lösung ist, als diese Berechnungen wiederholen zu müssen.
- Sie können bestimmte Instanzen eines Ereignisses bearbeiten. Wenn ein Meeting mit Tims Methode an einem Feiertag stattfindet und der Benutzer es auf den Vortag ändert, wie würden Sie es überhaupt tun? Wenn Sie die hier beschriebene Methode mit einem Eintrag pro Ereignis verwenden, können Sie diesen Datensatz für das Ereignis einfach ändern und einzelne Vorkommnisse einfach im Kalender verschieben.
