Datumsberechnungen

  • Original von contact
    Das mit der Datenbanklösung werde ich mal genauer unter die Lupe nehmen; möglicherweise bleibt alles überschaubar und man kann einem Kunden nach automatisch immer mal wieder anbieten, die Wiederholsachen zu "shiften", also aus der Vergangenheit nach vorn bringen; berechnet lägen die Termine ja in der DB. Die Zukünftigen Sachen müsste ich "heimlich nachrechnen" ... grübel grübel ...


    Ich sehe die Erwähnung der 2 Jahre stiftet nur Verwirrung - vergiss das. So denke ich könnte das hinhauen:

    In der Tabelle eine flag "is_repeating" und ein Timestamp "repeat_ends_stamp". Ein Event wird nur einmal reingeschrieben, wenn er wiederholend ist wird die flag gesetzt. Wenn das Enddatum berechnet werden kann, dann berechnen und reinschreiben, wenn nicht (Geburtstage, ...) bleibt es NULL.

    Die Abfrage nach überschneidenden Events ist dann einfach (my_## bezeichnet Daten des zu prüfenden Events):

    SQL-Abfrage

    1. SELECT ...
    2. WHERE
    3. (is_repeating = 0 AND end_stamp > my_start_stamp AND start_stamp < my_end_stamp) OR
    4. (is_repeating = 1 AND (
    5. repeat_ends_stamp IS NULL OR
    6. repeat_ends_stamp > my_start_stamp
    7. )


    Du erhältst dann die sicher überschneidenden, nicht-wiederholenden Events, und möglicherweise überschneidende, wiederholende Events. Jene Events, welche das is_repeating flag gesetzt haben, muss du dann basierend auf dem Intervall noch separat berechnen. Aber ich schätze mal dass das nur wenige sein werden, vor allem wenn du die App nach 5 Jahren noch benutzen willst. :)
    Widgetschmie.de • Life is too short for gadgets

  • Original von Pascal
    Du erhältst dann die sicher überschneidenden, nicht-wiederholenden Events, und möglicherweise überschneidende, wiederholende Events. Jene Events, welche das is_repeating flag gesetzt haben, muss du dann basierend auf dem Intervall noch separat berechnen. Aber ich schätze mal dass das nur wenige sein werden, vor allem wenn du die App nach 5 Jahren noch benutzen willst. :)


    das ändert aber nichts an der ganzen sache. Die abzufragen ist ja auch im code nur wenig arbeit - die andren sind die arbeit.

    Wenn man beim programmieren so denkt dass in "5" jahren das eh nimmer genutzt wird, dann hat man das selbe problem wie beim milleniumwechsel und co ;-))

  • Also so ähnlich hatte ich das schon im Kopf, um die Spreu vom Weizen zu trennen. Wobei ich das in getrennten Abfragen mache, weil mir OR-Statements immer Kopfschmerzen machen; bisher benötigten die immer mehr Zeit als einzelne ... hab ich aber noch nicht auf verscheidene Datenmengen bezogen evaluiert!

    In meiner ersten Abfrage benötige ich gerade mal ne 10tel sec für alle Termine des zu betrachtenden Zeitraumes, welcher meist nicht mehr als über 3 Monate hinausgeht, d.h. Blick auf ein Zeitfenster von 3 Monaten und was eben in dieser Zeit ansteht!

    Diese verflixten offenen Termine sind die Übeltäter. Hat jemand davon viele, spürt man deutlich den Performance-Verlust!
    Um Rekursion zu verstehen, muss man erst Rekursion verstehen!

  • Original von gritsch
    das ändert aber nichts an der ganzen sache. Die abzufragen ist ja auch im code nur wenig arbeit - die andren sind die arbeit.

    Klar. Mein Argument ist halt dass du so schon mal nur wenige Events bekommst, welche du dann im Code abfragen musst. Andernfalls musst du doch alle Events durchlaufen und das WHERE-Statement an den Instanz-Daten prüfen, das dauert bestimmt einiges länger. Hoffe ich jedenfalls, sonst ist die Datenbank Müll. ;)

    Original von gritsch
    Wenn man beim programmieren so denkt dass in "5" jahren das eh nimmer genutzt wird, dann hat man das selbe problem wie beim milleniumwechsel und co ;-))

    Das hast du falsch verstanden, ich meinte das so, dass das auch nach 5 Jahren noch einwandfrei funktioniert, weil du nicht alle Events der letzten 5 Jahre überprüfen musst. :)
    Widgetschmie.de • Life is too short for gadgets