Jag skulle bara skapa en post för varje återkommande händelse, ut mot någon horisont. Det betyder dock att du behöver en annan tabell som du kan använda för att projicera datumen om de skannar efter ditt horisontdatum. D.v.s. du behöver en händelsetabell som innehåller en post för varje förekomst av en upprepad händelse (1 januari, 8 januari, 15 januari, ... till december) och en tabell med varje post som är tillgänglig för kommande år (start datum:1 jan; upprepa:7; till och med:2011) så att du i början av 2012 (eller så snart användaren begär en vy av en 2012+ månad) kan generera framtida händelser.
Detta har två stora nackdelar:
- Din databas har data för ett helt år. Men om att lägga till ett helt års data förstör din prestanda, är ditt system förmodligen underdrivet. (Det verkar vara ett krav att en kalenderapp ska kunna hantera många års datum)
- I slutet av evenemangshorisonten måste du skapa framtida datum för återkommande evenemang.
Fördelarna (IMO) som överväger nackdelarna:
- Enklare matematik när du visar kalendern. Med hjälp av Tims metod ovan, om användaren laddar 18 december 2011, hur ska du beräkna vilka återkommande händelser som ska placeras den dagen? Du kommer att tvingas gå igenom VARJE återkommande händelse varje gång du visar ett datum. Avvägningen är nackdel #1, vilket jag tror är den bättre lösningen än att behöva göra om dessa beräkningar.
- Du kan redigera specifika instanser av en händelse. Med Tims metod, om ett möte inträffade på en helgdag och användaren ändrade det till föregående dag, hur skulle du ens göra det? Genom att använda metoden en-inträde-per-händelse som beskrivs här kan du bara ändra posten för händelsen och enkelt flytta runt enstaka händelser i kalendern.