Terugkerende afspraken bijhouden

[Lorn]

Ik ben bezig met een project waarin de gebruiker een taak moet kunnen inplannen. Bij het inplannen van de taak moet het mogelijk zijn om de taak te laten herhalen. Dit zou bijvoorbeeld kunnen zijn op iedere dinsdag maar het zou ook kunnen dat de taak iedere vier weken herhaald moet worden.

Taken kunnen ingepland worden met de nauwkeurigheid van een dag, het zal dus niet voorkomen dat een ingeplande taak wordt verschoven van 13.00 uur naar 15.20 uur op een bepaalde dag. Hooguit kan het gebeuren dat een taak wordt verplaats van dinsdag naar bijvoorbeeld donderdag en dit is dan van toepassing op alle instanties van de terugkerende afspraak die in de toekomst plaats vinden. Instanties van de terugkerende afspraak in het verleden moeten echter wel op hun originele dag te zien blijven in de kalender. Verder is er geen controle nodig of een herhalende afspraak conflicteert met een andere afspraak.

Het probleem dat ik heb is hoe ik de terugkerende afspraken zal opslaan. Ik zie grofweg twee oplossingen en ik weet niet wat het meeste praktische is, wellicht dat iemand hier me op de goede weg kan helpen?

Oplossing 1: On the fly
Wanneer in de kalender een dag of week wordt geselecteerd bepalen of er een terugkerende afspraak voorkomt. Er zal ergens opgeslagen moeten worden met welke frequentie een afspraak zich herhaalt en iedere keer wanneer er een datum of range van datums wordt getoond zal bepaald moeten worden of er een instantie van een herhalende afspraak optreed. Voor instanties die zijn geweest zou een losse afspraak opgeslagen kunnen worden waardoor oude instanties altijd zijn in te zien op dag dat ze hebben plaats gevonden.

Voordelen: Je maakt niet in één keer een hele berg afspraken aan. Door op te slaan met welke frequentie de taak uitgevoerd moet worden is het makkelijk om alle toekomstige instanties in één keer aan te passen.

Nadelen: Bij iedere handeling waar datums mee gemoeid zijn moet er worden gekeken of een herhalende afspraak zich voordoet. Om oude instanties te behouden zouden deze bij iedere start van de applicatie aangemaakt moeten worden als een losse afspraak.

Oplossing 2: Vooraf inplannen
Een andere oplossing zou zijn om wanneer de gebruiker een herhalende afspraak inplant, losse afspraken aan te maken voor een lange periode. Als een taak op iedere dinsdag gedaan moet worden zou de applicatie voor alle dinsdag in de komende tig jaar een afspraak kunnen aanmaken.

Voordelen: De afspraken zijn meteen klaar voor gebruik, er hoeft niet steeds gecontroleerd te worden of er een herhalende afspraak is op een bepaalde datum. Het is niet meer nodig om te controleren of een herhalende afspraak heeft plaats gevonden en daar een losse afspraak voor te maken zodat deze bewaard blijft als 'archief afspraak'.

Nadelen: Tot hoever in de toekomst plan je de afspraak in? Wanneer de frequentie veranderd zullen ook alle instanties van de afspraak in de toekomst aangepast moeten worden.

[BarthezZ]

Misschien niet direct relevant maar waarschijnlijk wel interessant voor je vraag:

Ik heb even het iCal (.ics) formaat gecontroleerd en hierin valt een regel te vinden als:

RRULE:FREQ=WEEKLY;UNTIL=20090701;INTERVAL=1;BYDAY=FR

Ik denk dat dus een hoop afspraken aanmaken sowieso not the way to go is, maar hoe je de recurrence wel daadwerkelijk handig en efficiënt in kan plannen zou ik niet kunnen beantwoorden.

[DutchCommando]

Toevallig staat hierover net een vraag open op StackOverflow.com. Zie daarvoor Design question: How would you design a recurring event system?

Allicht worden daar ook handige adviezen gegeven.

[ThunderNet]

Goed ik ga hier even heel erg in een gebruikersoplossing denken.
Maar wat als je de afspraken aanmaakt in outlook?
Mocht je het dan veranderen, dan kun je precies aangeven of je het ene event wil veranderen, of alle events (als je het aangemaakt hebt als recurring event).

[CodeCaster]

Interessant topic, ik heb deze vraag ook even door m'n hoofd laten gaan tijdens het schrijven van mijn kalender, een puur anti-vervelingprojectje dat nu op pauze staat.

Instanties van de terugkerende afspraak in het verleden moeten echter wel op hun originele dag te zien blijven in de kalender

Dan zou ik gaan voor de optie voor het meerdere malen opslaan. Geef de gebruiker de keuze om een verwachte tijdsduur. Zo kan ik bijvoorbeeld een week op dinsdag moeten werken, maar dat kan over twee maanden best verplaatst worden naar woensdag. Als ik dan terugkijk in mijn kalender moet de dinsdag dan nog wel als bezet staan.

[Lorn]

BarthezZ schreef op dinsdag 23 september 2008 @ 22:35:
[...]


Ik denk dat dus een hoop afspraken aanmaken sowieso not the way to go is, maar hoe je de recurrence wel daadwerkelijk handig en efficiënt in kan plannen zou ik niet kunnen beantwoorden.

Ik moet toegeven dat het in één keer aanmaken van een hoop afspraken ook niet juist voelt maar de voordelen vind ik dan toch wel weer aantrekkelijk.

DutchCommando schreef op dinsdag 23 september 2008 @ 23:58:
Toevallig staat hierover net een vraag open op StackOverflow.com. Zie daarvoor Design question: How would you design a recurring event system?

Allicht worden daar ook handige adviezen gegeven.

Bedankt, een zeer nuttige link! Ik ga dat topic zeker goed in de gaten houden.

CodeCaster schreef op woensdag 24 september 2008 @ 00:12:
Interessant topic, ik heb deze vraag ook even door m'n hoofd laten gaan tijdens het schrijven van mijn kalender, een puur anti-vervelingprojectje dat nu op pauze staat.

[...]

Dan zou ik gaan voor de optie voor het meerdere malen opslaan. Geef de gebruiker de keuze om een verwachte tijdsduur. Zo kan ik bijvoorbeeld een week op dinsdag moeten werken, maar dat kan over twee maanden best verplaatst worden naar woensdag. Als ik dan terugkijk in mijn kalender moet de dinsdag dan nog wel als bezet staan.

Als ik altijd vraag om een uiterste datum tot wanneer de terugkerende afspraken aangemaakt moeten worden treedt het risico op dat de gebruiker daarna vergeet de taak opnieuw in te plannen voor een volgende periode.

Daarom zit ik er aan te denken om terugkerende afspraken on-the-fly weer te geven en om bij het starten losse afspraken op te slaan voor de instanties van de afspraak die al hebben plaatsgevonden. Volgens mij heb ik dan het beste van twee oplossingen.

Een mogelijke derde oplossing zou zijn om meerdere versies van de terugkerende afspraak bij te houden. Wanneer een terugkerende afspraak wordt aangemaakt zou deze dan altijd een startdatum krijgen en gelabeled worden als versie 1. Wanneer de gebruiker de terugkerende afspraak aanpast zou het origineel een einddatum krijgen gelijk aan de datum waarop de aangepaste versie is opgeslagen. De aangepaste versie heeft dan weer alleen een startdatum en krijgt versie 2 als label. Bij het aanpassen van de afspraak zou dan altijd de laatste versie getoond moeten worden.

[Cuball]

Wij hebben ook een kalender systeem gebouwd volgens jou oplossing 1, nu in een vervolg project gaan we deze oplossing vervangen door de jou gegeven oplossing 2!

Het on the fly tonen van een agenda is allemaal goed te doen, maar de problemen starten pas wanneer je moet zoeken naar open gaatjes en dergelijke of als er data extracties moeten gebeuren (voor bv. in datawarehouse). Je hebt namelijk niets in je tabellen staan van fysieke records die in de toekomst gelegen zijn.

Een tussen oplossing die wij gebruiken is om data extracties te doen is effectief na verlopen van de datum deze records gaan wegschrijven in een tabel!

Ook het overschrijven van entry's kan voor koppijn zorgen!

Oplossing 2 heeft inderdaad het probleem tot waar ga je plannen, maar dit zou je mits goed overleg moeten kunnen afspreken met de klant

[alienfruit]

Handig. Ik ben bezig om een vervangende applicatie te bouwen voor Calendar op de iPhone.

[w!mz]

Ik zou gaan voor oplossing 2 in combinatie met 2 tabellen. 1 Tabel waarin je je taken vastlegt en 1 tabel waarin je vastlegt wanneer de taak voorkomt. Tussen deze 2 tabellen zit een 1:N relatie; immers 1 taak kan meerdere keren voorkomen. Opzet ziet er dan als volgt uit

tabel_taak: velden --> uniekID, userID, titel, omschrijving,
tabel_taak_afspraken: velden --> uniekID, tabel_taak.uniekID, tijdVanTaak

Op deze manier kan je alle dagen waarop een taak is ingepland ophalen via tabel_taak_afspraken. Door middel van een groter dan statement kan je alle "taak afspraken" die in de toekomst vallen in 1 rits veranderen.

Hoever je de toekomst inplant zou ik laten afhangen van de keuze van de gebruiker. Een knopje 'Nu komt deze taak nooit meer voor, delete alles in de toekomst' zou handig zijn om alles een beetje schoon te houden. Voor dit laatste hoef je dan alleen de instances uit tabel_taak_afspraken te verwijderen met tijdVanTaak > tijd.NU.

Hoop dat dit je verder helpt

[Lorn]

Cuball schreef op woensdag 24 september 2008 @ 10:17:
Wij hebben ook een kalender systeem gebouwd volgens jou oplossing 1, nu in een vervolg project gaan we deze oplossing vervangen door de jou gegeven oplossing 2!

Het on the fly tonen van een agenda is allemaal goed te doen, maar de problemen starten pas wanneer je moet zoeken naar open gaatjes en dergelijke of als er data extracties moeten gebeuren (voor bv. in datawarehouse). Je hebt namelijk niets in je tabellen staan van fysieke records die in de toekomst gelegen zijn.

Een tussen oplossing die wij gebruiken is om data extracties te doen is effectief na verlopen van de datum deze records gaan wegschrijven in een tabel!
[...]

Grappig en toevallig dat jullie dezelfde oplossingen hebben De tussenoplossing die je beschrijft heb ik ook aan lopen denken en daar voel ik toch nog het meest voor. Het vinden van open gaatjes is bij mij geen issue, taken kunnen op dag gepland worden en niet per uur of zo. Data extractie zie ik wel gebeuren, vandaar dat de tussenoplossing mij wel aanspreekt.

w!mz schreef op donderdag 25 september 2008 @ 00:03:
Ik zou gaan voor oplossing 2 in combinatie met 2 tabellen. 1 Tabel waarin je je taken vastlegt en 1 tabel waarin je vastlegt wanneer de taak voorkomt. Tussen deze 2 tabellen zit een 1:N relatie; immers 1 taak kan meerdere keren voorkomen.

[..]

Bedankt voor je mogelijke oplossing. Ik heb er even over nagedacht maar volgens mij heb je minstens drie tabellen nodig. In de structuur zoals jij hem voorstelt kun je namelijk nooit meer laten zien met welke frequentie de taak is ingepland. Je zult dus ook nog een tabel nodig hebben om de regel in vast te leggen voor het terugkeren van de taak.

Je oplossing ondervangt echter niet mijn grootste probleem. Ik heb in principe geen einddatum voor mijn terugkerende afspraak en dat betekent dat ik dan voor de komende tig jaar alle afspraken los zou moeten inplannen en dat kan volgens mij toch echt niet de bedoeling zijn.

[w!mz]

Bedankt voor je mogelijke oplossing. Ik heb er even over nagedacht maar volgens mij heb je minstens drie tabellen nodig. In de structuur zoals jij hem voorstelt kun je namelijk nooit meer laten zien met welke frequentie de taak is ingepland. Je zult dus ook nog een tabel nodig hebben om de regel in vast te leggen voor het terugkeren van de taak.

De frequentie van de taak kan je vastleggen in de tabel waarin je je taken vastlegt; een extra veld met daarin opgeslagen 'wekelijks' '2 wekelijks' 'maandelijks'. Veranderen van de frequentie kan door alle afspraken na een bepaald punt weg te gooien en opnieuw in te voeren met de nieuwe frequentie.

Je oplossing ondervangt echter niet mijn grootste probleem. Ik heb in principe geen einddatum voor mijn terugkerende afspraak en dat betekent dat ik dan voor de komende tig jaar alle afspraken los zou moeten inplannen en dat kan volgens mij toch echt niet de bedoeling zijn.

Dit lijkt mij geen probleem wat je programmatuurtechnisch wilt oplossen, maar door middel van een procedure waarin je aangeeft dat gebruikers moeten nadenken hoevaak een taak zich ongeveer zal herhalen. Je zou een maximum van 3 maanden vooruit plannen in kunnen bouwen; en elke week met een automatische taak (niet vergeten te schedulen ) alle niet gestopte taken een week door kunnen trekken.

[Lorn]

w!mz schreef op donderdag 25 september 2008 @ 12:23:
[...]


Dit lijkt mij geen probleem wat je programmatuurtechnisch wilt oplossen, maar door middel van een procedure waarin je aangeeft dat gebruikers moeten nadenken hoevaak een taak zich ongeveer zal herhalen. Je zou een maximum van 3 maanden vooruit plannen in kunnen bouwen; en elke week met een automatische taak (niet vergeten te schedulen ) alle niet gestopte taken een week door kunnen trekken.

Het is echt niet mogelijk om aan de gebruiker te vragen hoelang een taak terugkerend moet zijn. Een taak kan tot in een lengte van dagen blijven doorlopen.

Waar ik ook al aan had gedacht is om terugkerende afspraken tot een bepaald punt in de toekomst te plannen, bijvoorbeeld drie maanden. Wanneer de gebruiker via de kalender verder dan drie maanden vooruit kijkt kan de periode die nog niet is gedaan op dat moment gekeken worden welke terugkerende afspraken er binnen vallen.