hmmm ja.
so langsam komme ich auch zu der Einsicht, dass diese zwar aufwendige, aber einleuchtende Lösung, die bessere ist.
Danke trotzdem allen Beteiligten!

was ist eigentlich, wenn ich einen Termin habe, der immer Freitags stattfindet. Ich kann doch dann nicht einfach Datensätze für 10 Jahre anlegen.
Da wäre es ja fast sinnvoller, eine Tabelle nur für die Termine anzulegen, die NICHT stattfindet bzw. storniert werden.

also vielleicht solltest du dich an den Use Cases anderer Terminplanern orientieren:

Wenn ich z.B. bei Google Calender einen serientermin bearbeite fragt er mich, ob die Änderung

a) nur an diesem Termin
b) allen Serienterminen
c) allen folgenden Terminen

ausgeführt werden soll.

Nach der Änderung wird "geclont", d.h. die geänderten Termine haben keinen Zusammenhang mehr zur ursprünglichen Serie.

Hört sich einfach an!

Die von KurtZ beschriebene Methode wird so auch beim Palm verwendet. Einzelne Termine in einer DB zu speichern ist ja noch relativ einfach, nur wie macht man das (wirklich) sinnvoll bei Serienterminen?

Ich hatte mal folgendes Konzept entworfen, bin aber damit noch nicht weiter gekommen:

* id_eintrag (PRIMARY KEY)
* id_kalender (FOREIGN KEY; für mehrere Kalender)
* typ (-> 'eintrag', 'ausnahme', 'zusatz')
* datum_von (Pflicht-Feld)
* datum_bis (Pflicht-Feld)
* uhrzeit_von (Kann-Feld)
* uhrzeit_bis (Kann-Feld)
* titel (Pflicht-Feld)
* beschreibung (Kann-Feld)
* alarm (Kann-Feld; Datum + Uhrzeit)
* Kategorie (Kann-Feld)
* ts (Timestamp; z.B. für Synchronisationen)
* wh_typ ('keine', 'tag' -> tägliche Wiederholung, 'woche' -> ..., 'monat_wochentag' -> monatlich an diesem Wochentag (z.B. jeden 2. Donnerstag im Monat), 'monat_datum' -> monatlich an diesem Datum (z.B. jeweils am 5.), 'jahr' -> ...)
* wh_periode (alle X Tage, X Wochen, X Monate, X Jahre (z.B. nur jeweils jeder dritte Tag/Woche/Monat/Jahr; ist abhängig von wh_typ))
* wh_typ_woche_wochentag (wenn wh_typ = wöchentlich, dann können hier Wochentag (Mo, Die, ...) angegeben werden
* wh_sonder (-> id_eintrag; hier können Verweise auf Ausnahmen definiert werden, z.B. dass ein zusätlicher Termin (nicht) stattfindet)

(wh = Wiederholung)

Durch mögliche Wiederholung und Ausnahmen ist das etwas komplizierter geworden, leider auch bei der Eingabe und Anzeige von Terminen. Aber eigentlich müssten damit jede Art von Termin machbar sein.

Hagen+2008-03-13 09:57:09--

Durch mögliche Wiederholung und Ausnahmen ist das etwas komplizierter geworden, leider auch bei der Eingabe und Anzeige von Terminen. Aber eigentlich müssten damit jede Art von Termin machbar sein.

Wie würdest Du den Ausfall eines Termines kennzeichnen oder die Verschiebung auf einen anderen Wochentag?

Gruss

Dirk

Ich möchte die "beschreibung"-Spalte ungern jedesmal klonen müssen.
Aber Hauptproblem sind halt auch solche Dinge wie z.B.: "Jeden Freitag". Soll ich dann Datensätze für 10 Jahre im Vorraus anlegen? Wie macht denn der Parlm sowas?

Froschpopo+2008-03-13 13:42:08--

Ich möchte die "beschreibung"-Spalte ungern jedesmal klonen müssen.

falscher geiz?

Froschpopo+2008-03-13 13:42:08--

Aber Hauptproblem sind halt auch solche Dinge wie z.B.: "Jeden Freitag". Soll ich dann Datensätze für 10 Jahre im Vorraus anlegen? Wie macht denn der Parlm sowas?

verlangt das jmd? Sorry ich kann die vorhergehende SQL-diskussion nicht nachvollziehen...

Ich würde jeden Termin als Serie darstellen, d.h. mit Wiederholungsintervall, erstem und letztem Geltungstag. Ein einmaliger termin hat halt Intervall 0 und gleiche Begrenzer.


Wenn du einen einzelnen Eintrag verschiebst clonst du diesen und gibst ihm einen neuen Termin. Gleichzeitig trägst du beim alten Eintrag in einer Ausnahmeliste einen Termin ein.

Bei der Darstellung der Einträge eines Zeitraums suchst du halt in der DB was passt.

Also

Eintrag
-> Termin
-> Ausnahmen
-> Beschreibung

Termin
-> Anfang
-> Ende
-> Intervall

Ausnahmen
-> Termin1
-> Termin2
-> ...

Das klonen ist vielleicht Datenbanktechnisch unelegant, aber schließlich soll der user auch intuitiv damit umgehen können und wie willst du ihm normalsprachlich die Konsequenzen vermitteln wenn die Änderung der Änderung einer Änderung mit dem Original zusammenhängt? Dann darfst du Abhängigkeitsbäume darstellen...

EDIT: ich weiß jetzt nicht wie Googlecalender damit umgeht wenn das Intervall eines Eintrages geändert wird nachdem ein einzelner Termin rausgelöscht wurde, die Recherchearbeit überlasse ich jetzt aus Zeitmangel dir :)

EDIT2: Ok ich war neugierig, bei einer Verschiebung eines Einzeltermins bei GC wird NICHT geklont, Wird später die Beschreibung geändert wirkt sich das auch auf die Verschiebungen aus. Wird später das Intervall geändert verfallen automatisch alle Ausnahmen. => es gibt wohl eine interne Ausnahmeliste.
Zusätzlich kennt GC die möglichkeit einen Termin zu "doppeln" dort wirken sich Änderungen der Beschreibung nicht mehr aus.=> Cloning!
Da GC es selbst nicht schafftdieses Verhalten in der Hilfe zu beschreiben, denke ich ist von dir jetzt gefordert erst mal dein UseCase zu durchdenken udn dann erst ein Datrenmodell zu stricken, sonst reden hier alle aneinander vorbei.

das wird sau schwierig! Lassen wir die Ausnahmen-Liste erstmal weg und gehen wir von einem einzelnen Datensatz aus.
Wie muss denn dann hinterher die Schleife aussehen die mir 4 Monate darstellt?

Dann erstelle ich also mit Date::Calc eine Liste aller Tage die in diesen Zeitraum passen und mache dann für jeden Tag ein SQL-SELECT welches mir zeigt, ob ein Termin an diesem Tag stattfindet.

Hier beginnt das eigentliche Problem: Es muss nämlich nicht nur für jeden Tag ein SELECT gemacht werden, sondern auch für jede Intervall-Möglichkeit.

Mal ein Beispiel:
Angenommen wir wollen gucken, welche Termine am 20 März stattfinden.
Dann muss ich ja auch erstmal wissen, für welchen Intervall ich entsprechend zurückrechnen muss!
Wenn mich mein logisches Verständnis nicht täuscht, dann müsste ich auch alle Intervalle (täglich, zwei-tägig, wöchentlich, zwei-wöchig, monatlich usw.) in einzel-Selects durchgehen und dann entsprechend zurückrechnen.
Das war das, wovor ich mich gefürchtet habe.
Diese Ausnahmen (Terminausfälle, Umbuchungen etc.) sind da wohl eher eine Nebensache.

Froschpopo+2008-03-13 15:47:36--

Wie muss denn dann hinterher die Schleife aussehen die mir 4 Monate darstellt?

Ich würde es so machen, dass ich die Termine für jeden Tag "ausrechne" und dann auch darstelle.

Froschpopo+2008-03-13 15:47:36--

Dann erstelle ich also mit Date::Calc eine Liste aller Tage die in diesen Zeitraum passen und mache dann für jeden Tag ein SQL-SELECT welches mir zeigt, ob ein Termin an diesem Tag stattfindet.

Ich würde beispielsweise die Datean als "Unix-Zeit" speichern, das erleichtert die Rechnerei enorm.

Froschpopo+2008-03-13 15:47:36--

Hier beginnt das eigentliche Problem: Es muss nämlich nicht nur für jeden Tag ein SELECT gemacht werden, sondern auch für jede Intervall-Möglichkeit.

Wenn der Startzeitpunkt des Anzeigeintervalls kleiner ist als das Ende der Terminserie und das Ende des Anzeigeintervalls hinter dem Start der Terminserie liegt, hast Du Termine in der Zeit, wenn das Intervall stimmt.

Das bleibt dann noch zu prüfen.

Froschpopo+2008-03-13 15:47:36--

Diese Ausnahmen (Terminausfälle, Umbuchungen etc.) sind da wohl eher eine Nebensache.

Ich finde, dass es gerade die Ausnahmen schwierig machen.

Gruss

Dirk

lux+2008-03-13 13:28:35--

Wie würdest Du den Ausfall eines Termines kennzeichnen oder die Verschiebung auf einen anderen Wochentag?

Nach meinem Datenmodell findet der Termin erstmal durch die periodische Eingabe statt. Dann wird ein zusätzlicher Termin (automatisch) angelegt, vom typ='ausnahmen', dessen id in wh_sonder steht.

Falls ein Termin nicht vom Typ 'eintrag' ist würde ich (bis auf Datum und Zeit) die Daten von dem Stamm-Termin nehmen. So würde für jeden Termin wirklich nur ein Eintrag angelegt werden ... bis auf die Ausnahmen.

Wie der Palm das intern macht, kann ich nicht sagen ... aber diese Art von Ausnahmen beherscht er nicht. Vielleicht wäre das iCal-Modell mal ein Blick wert ... Date::ICal