Borlox

Hallo alle zusammen,

ich erstelle gerade ein "kleines" Groupwaresystem in php und habe folgendes Problem bei der Erstellung der Termine für meinen Kalender:

Ich möchte, wie es auch in anderen Systemen möglich ist, Serientermine anlegen können, also wenn jemand einen Termin angibt, dass er dann z.B. auf wöchentlich klickt und dann kommt der Termin jede Woche wieder! Das ganze natürlich auch Monats- und Jahresweise! Wie würdet ihr das am Besten realisieren? Wollte das erst in extra Tabellen schreiben, aber es soll ja die Möglichkeit geben, wieder Termine aus der Serie raus zu nehmen. Nun könnte ich zwar einfach den Termin immer wieder kopieren und in meine DB speichern, aber dann würde sich diese ja ins unermessliche aufblähen. Wenn z.B. Leute wöchentliche Termine angeben und das bis ins Jahre 2050 oder so! Dann ist die Performance ja gleich im Arsch!

Jemand ne performante Idee?

Gruß Borlox

Mister Ad

Zergling-new

Du willst also periodische Events mit Ausnahmen (wöchtenlich, aber nicht am 27. April 2006 zB) eintragen können?

Hm ich würde das so lösen, dass ich in der Event-Tabelle einen Flag setzen würde, ob es sich um einen periodischen Eintrag handelt

id | start (DATE) | end (DATE) | periodtype (TINYINT) | name | ...

periodtype würde ich dann
0 für "nicht periodisch"
1 für "wöchentlich"
2 für "monatlich"
3 für "jährlich"
(oder vierteljährlich, wie auch immer)

so setzen und in einer Extra-Tabelle eine Blacklist der Periodentermine führen, die eben für Ausnahmen stehen

id | event_id | not_in_period (DATE) | instead (DATE)
instead eventuell für "abnormalen" ausweichtermin, könnte aber auch als "normaler" Event in die Eventtabelle eingetragen werden


Naja bei Abfragen kannst du jetzt normal alle Termine ausgeben, die zwischen "start" und "end" liegen, wenn "periodtype" ungleich 0 ist, musst du eben nochmal gesondert rechnen, da gibts ja Datumsfunktionen die dir jeweils Tage, Monate oder Jahre zu einem Datum ("start") hinzufügen können. Könnte dann halt ein längeres Statement werden, aber so ist es halt.

Zusätzlich muss noch rein, ob die Periode nicht genau heute auf einen Blacklist-Eintrag fällt.


Das wäre jetzt meine Idee. Find ich aber ganz sauber, praktisch hab ichs aber nie so gemacht (da hab ich nur jährliche Events in meinen Kalender übernommen, mit Jahresangabe 0000 und dementsprechendem SQL WHERE datum = '0000-...' or datum = '2006-...', nicht gerade erste Sahne, aber hatte keine Zeit für mehr damals)

Borlox

Joa, hört sich schon sehr interessant an. Kennt ihr noch mehr Möglichkeiten, muss mich ja nicht gleich für die Erste entscheiden?

Hat es irgendeinen Vorteil für dich, wenn du deine Dates im Format 'YYYY-MM-DD' speicherst? Ich mach das immer mit Timestamps, da ich damit dann ja ein wenig einfach umgehen kann???

Gruß Borlox

Zergling-new

Ich mag Timestamps net so, weil wenn ich in die DB guck, will ich sehen und gleich verstehen was da ungefähr für ein Datum/Zeit steht.

Außerdem hab ich dann nicht die Beschränkung auf 1970 und kann so alle Daten auch als Datum darstellen (Geburtstage) und muss keine Kompromisse eingehen (mal Timestamps mal DATE(TIME)).

Auf andere Ideen wär ich aber auch mal gespannt zum Thema..

Borlox

Naja, das man das gleich in der DB sieht, finde ich nicht so wichtig, dazu bastel ich mir ja auch meine Oberfläche! Und wenn ich mich nicht irre, dann kann man auch Timestamps im Minus-Bereich anlegen (mache ich in meiner DB mit Geburtstagen), nur Windowsserver haben kleinere Probleme damit, wenn das Datum dann vor 1902 oder so kommt, dann wird die Zahl ZU negativ, dass kann Windows dann nicht mehr Beispielen oder so! Hatte das letztens mal rechachiert (<-- keine Ahnung, wie man das richtig schreibt)!

Gruß
Dustin

webazubi

Um das Thema nochmals aufzuwärmen ...

Ich hatte mich vor längerem mal mit den Serienterminen beschäftigt und auch im Forum die Frage gestellt, ob es (aus Gründen der Abfragegeschwindigkeit) sinnvoller sei,
(A) die Serientermine alle als einzelne Datumswerte (für jeden Tag eines Termines je einen Datensatz) einzugeben oder eben
(B) die Berechnung über weitere Verknüpfungen und Intervalle (wie wöchentlich, monatlich usw.) zu basteln, so dass pro Terminserie nur ein Datensatz entsteht.

Damals wurde mir geraten, die Termine alle einzeln in die Datenbank einzutragen (A), weil dadurch die Abfragegeschwindigkeit gegenüber der "Einzelfall-Berechnung" steigt.
Nun lese ich aber hier im Forum immer öfter die andere Variante, dass also online per MySQL oder PHP ein Datum daraufhin untersucht werden soll, ob es in einen Zeitraum fällt, der durch einen Serientermin abgedeckt wird (B).

Ich habe (für eine Internetzeitung) sehr viele Einzeltermine und Terminserien. Allein die Öffnungszeiten von vielen Einrichtungen, die ich mit in meiner Datumsabfrage einbauen will, spricht eher für die Intervallvariante (B).

Aber wenn ich mir vorstelle, dass online jeder sagen wir zweite Termin auf das Intervall untersucht werden soll, dann dauert doch auch das ewig!? Ich kann die Abfrage natürlich eingrenzen, aber ich sehe es doch richtig, dass PHP oder MySQL jeden Termin, der mit einem Intervall verknüpft ist, in einem Array bzw- Abfrage ausführen muss, um dann diese Ergebnisse mit dem gewünschten Datum zu vergleichen?
Sprich: Habe ich einen Datensatz, der am 15.01.2006 begann und über einen Wert "w" als wöchentlicher Termin gekennzeichnet ist, dann müsste ich per Array/Abfrage simulieren 15.01.; 22.01;29.01 .. (alle 7 Tage) um dann zu schauen, ob heute der Termin läuft.

Das sind doch irre Rechenoperationen, oder? Also scheint die direkte Eingabe aller Termine in die Datenbank doch besser zu sein?

Zergling-new

Spontan würde ich schauen, ob der eingetragene Termin, der wöchentlich stattfindet den selben Wochentag hat, wie der gesuchte.

Meinem Beispiel oben entsprechend:
SELECT * FROM calendar WHERE (periodtype = 0 AND start = #GESUCHTES_DATUM#) OR (periodtype = 1 AND (#GESUCHTES_DATUM# BETWEEN start AND end) AND WEEKDAY(start) = WEEKDAY(#GESUCHTES_DATUM#))

Das ist für MySQL kein Problem.

Zergling-new

Andererseits ist das ein blödes Gefrickel in einer Tabelle wöchentlich/monatlich/1/x-jährliche Termine unterzubringen.

Vielleicht hat ja jemand den anderen PHP-Kenner einen Alternativ-Vorschlag?

Nur dann, wenn Du es genauso irre berechnest. Die Datum- und Zeitfunktionen von MySQL für DATETIME Spalten sind da sehr effizient.

Sehe ich nicht so. Zu unterscheiden braucht man letztlich nur zwischen einmalig, täglich und monatlich.

Man setzt also wie von Dir oben vorgeschlagen in einem Feld (periodtype) die Art des Intervalls:

• 0 für "nicht periodisch"
• 1 für "täglich"
• 2 für "monatlich"

Die anderen periodischen Termintypen lassen sich dann über ein weiteres Feld (quantity), das die Anzahl der jeweiligen Periode angibt, abhandeln.

Beispiel:

• periodtype = 2, quantity = 12 => jährlich
• periodtype = 1, quantity = 4*7 => vierwöchentlich
• periodtype = 2, quantity = 3 => vierteljährlich
• usw.