Gentagelser i kalender

Jeg går ud fra, at du udskriver kalenderen med dens begivenheder i en php applikation på basis af en database-select for de relevante begivenheder.  Hvis du vil udskrive en kalender for juli 2014 går du ind i databasen og selecter begivenheder hvis startdato ligger i juli.  Hvis du vil udskrive en kalender over foredrag selecter du begivenheder med kategori foredrag.

Hvis det er nogenlunde rigtigt, så er mit spørgsmål hvodan du gemmer begivenhederne i databasen.  Har du en tabel med begivenheder hvor hver begivenhed er en række i tabellen?  I så fald vil jeg mene, at du kan gemme dine gentagelses-begivenheder i et enkelt felt i original begivenheden.  Begivenheder der ikke gentages får 0 i feltet.  Begivenheder der gentages ugenligt får 7 i feltet.  Hvis du har begivenheder der gentages månedligt kan du skrive 'm' i feltet.  Når du så selecter begivenhederne indenfor den relevante tidsramme eller kategori, så skal du også selecte de begivenheder der ikke har nul i gentagelsesfeltet.  Det 'oversætter' du så i php.  Hvis for eksempel du har et moderne-kunst-foredrag 4 juli 2014 og den begivenhed har 4 i gentagelsesfeltet, så udskriver du også et moderne-kunst-foredrag 8 juli og 12 juli og 16 juli o.s.v.

Ja applikationen skrives i PHP med MySQL som database, men i princippet er det underordnet, da jeg blot vil høre jeres holdninger til, hvordan strukturen bør være.

Jeg ville gerne kunne gentage begivenheder baseret på X antal dage, uger, måneder eller år. I princippet kunne dette jo så løses med en kolonne i database til antallet af dage, og når vi så kommer til månederne kunne man passende lave en kolonne til dette også, da en måned jo svinger mellem 28-31 dage. Dette kunne såmænd sagtens omsættes til parametre i en select-forespørgsel, så alle begivenheder ikke skal hentes ind i PHP og gennemløbes.

Jeg giver brugeren mulighed for at vælge imellem et bestemt antal gentagelser eller en fast slut-dato. Slut-datoen kunne i princippet altid udregnes ud fra det valgte mønster, så det er dybest set heller ikke et problem.

Så kommer vi dog til, at jeg gerne vil kunne tilknytte kommentarer og andre informationer til en enkelt forekomst af en begivenhed - selvom der måske er mange gentagelser. Nogen forslag hertil?

I princippet kan man jo gennemløbe dagene en uge frem, og så oprette begivenheden ud fra det gemte mønster i databasen, men tænker det må kunne laves smartere...

Jeg deler det i to.  (1)  Brugerne opretter begivenheder enten som engangs eller gentaget med bestemte mellemrum, antal dage eller måneder, og med en begrænsning, antal gange eller indtil en bestemt dato. Hvis der ikke havde været noget med kommentarer til enkelte forekomster ville jeg simpelt hen oprette 'grund-begivenheden' som en række i en 'begivenheds-tabel' med, blandt andet, en kolonne for id, en kolonne for startdato, og så en kolonne for antal gentagelser, som vil være 0 for engangsbegivenheder, en kolonne for interval, en kolonne for intervaltype, dage eller måneder, og en kolonne enten for antal gentagelser eller for slutdato.  I php skal du så enten omregne slutdatoer til antal gentagelser eller omregne antal gentagelser til en slutdato.  Spørgsmål:  Hvad skal der ske, hvis brugeren opgiver en umulig slutdato?  Hvis for eksempel startdato er 1 juli, begivenheden gentages hver anden dag, og slutdato opgives til 14 juli?
(2)  Så det med kommentar til en enkelt forekomst.  Hvordan identificerer du hvilken forekomst skal have kommentaren?  Hvis et foredrag over moderne kunst skal have fem forekomster, kommer der så for eksempel en kommentar til forekomst nummer to og en anden kommentar til forekomst nummer tre?  Hvis kommentarer knyttes til et forekomst-nummer vil jeg foreslå at gemme kommentarerne i en separat forekomst-tabel med en en-til-mange relation til begivenheds-tabellen.  Forekomst-tabellen får så (mindst) tre kolonner, en id, en begivenheds-id, og kommentar.  Hvis kommentarerne ikke knyttes til et forekomst-nummer, så kommer du nok til at forklare hvordan så.

1) det er rigtigt forstået. Såfremt brugere har valgt startdato 1. juli og slutdato d. 8 juli, men med gentagelse hver anden dag, ja så  gentages begivenheden indtil da, dvs. d. 1, 3, 5 og 7. juli. Mønsteret gentages altså til og med den valgte slutdato.

2) Det er jo så netop essensen i spørgsmålet. Jeg skal jo netop finde en god måde at gøre dette på. Men der er 4-6 andre informationer, der også kan ændres pr begivenhed (sted, deltagere m.fl.), så min tanke var lidt, om jeg skulle lave en grund-tabel til begivenheden som også indeholder information til gentagelse, som beskrevet i din (1) fra svar #3, samt en tabel til ændringer altså overordnet med felterne 'begivenheds-id', 'key' samt 'værdi'. Hvor man altså så har en række pr information, der afviger fra standarden.

3) Dog tænker jeg at det mere og mere lyder som om jeg blot burde lave en kopi af det oprindelige event på dagen, og så modificere denne.

Lad mig høre dine tanker

Ved du hvad, jeg står af her, du bliver ved med at udvide spørgsmålet.  Jeg har allerede givet dig mine tanker (derfor opretter jeg dette som svar): en tabel for grundoplysningerne og en anden tabel for det der er specielt for de enkelte forekomster.  Det følger også gængs praksis i database design at undlade at kopiere data.  Dine egne tanker kan naturligvis være nogle andre, og i såfald følger du naturligvis dem.

Jeg ville såmænd blot undgå at skrive alt for meget indledningsvis, da jeg var bange for at det ville skræmme folk væk :)

Jeg siger tak for dine tanker og synspunkter omkring strukturen. Jeg vil også lige tillade mig at linke til en diskussion, der har nogle gode konkrete forslag til opbygningen også:
http://stackoverflow.com/questions/5183630/calendar-recurring-repeating-events-best-storage-method

Det er godt, at spørgsmålet er lukket nu.  Jeg mener stadig det er bedst i det oprindelige spørgsmål at forklare problemstillingen fuldt ud, så folk har en chance for at hjælpe hvis de kan.  Du vil have begivenheder i kalenderen hvor grundoplysningerne er ens men detaljer er forskellige.  Det er en velkendt problemstilling i database design, for eksempel kundeordrer hvor kundens navn, nummer, o.s.v., er ens, men hvor de bestilte varer er forskellige, og løsnisngen er velkendt, nemlig tabeller med 'en-til-mange' relationer.  Det er en væsentlig anden problemstilling end begivenheder der gentages med faste mellemrum.  Men vi kom til en ende, og når enden er god er alting godt.