ChrisB: Zeitperioden vergleichen mit MySQL und PHP + Zend Framework

Beitrag lesen

Hi,

ich komme bei einer Aufgabe nicht (effizient) weiter und bin auf Euer Rat angewiesen.

Angesichts des Titels möchte ich erst mal vorschlagen - lass' das Framework aussen vor, lass' PHP aussen vor, lass' die DB/SQL aussen vor.
Zuerst mal will die Logik überlegt sein, da steckt der eigentliche (Denk-)Aufwand. Die Umsetzung ist dann anschließend eher ein Fliegenschiss.

Es gibt eine Datenbanktabelle, die aus 7 Spalten besteht:
id, begin_year, begin_month, begin_day, end_year, end_month, end_day

Jede Zeile in der Tabelle repräsentiert eine Zeitperiode, wobei Spalten "*_year" und "*_month" gleich NULL bzw. nicht angegeben sein können.

Datumsangaben sollten normalerweise nicht auseinander gerissen werden, aber hier bleiben vermutlich keine anderen Möglichkeiten. DATETIME bspw. würde es zwar auch erlauben, den Year-Part auf 9999 zu setzen, damit könnte man eine „Wildcard“-Jahresangabe zwar auch umsetzen (wer hat Angst vor Y10K?) - aber für den Monat gibt's nichts vergleichbares.

Ein paar Beispielperioden für bessere Interpretation (Zahl am Anfang ist eine ID):

2 | 15.12.2010 - 15.01.2011 (über Silvester)
3 | 10.06.* - 20.09.* (gilt für jedes Jahr)

Hier musst du dir aber überlegen, wie du eine Eindeutigkeit rein bringst.
Ist das nur vom 10.6. eines Jahres bis zum 20.09. des gleichen Jahres - oder kann/darf eine darauf „passende“ Suchperiode auch vom 10.6.2007 bis zum 20.09. 2015 gehen ...?
Hier könnte man ggf. noch verlangen, dass das Jahr bei beiden Referenz-Datümern das gleiche sein soll - aber das haut beim Beispiel darüber (oder den später folgenden Beispielen #6 und #7) schon nicht mehr hin, wenn dort das Jahr auch mal auf beiden Seiten „*“ sein sollte.

4 | 10.*.* - 20.*.* (gilt für jeden Monat und jedes Jahr)

Auch hier wieder - nur die jeweils gleichen, oder auch vom 10.4. bis zum 20.08.?

Es wird eine Formel (oder Algorithmus) gesucht, die alle Perioden (aus der Datenbank) findet, die für (im Webformular) angegebene Periode passend sind.

Ich denke, obige Fragen müssen erst mal geklärt bzw. dafür eine Definition gefunden werden, bevor du weiter machen kannst.

Es wäre eine große Hilfe, wenn mir jemand einen Lösungsvorschlag oder eine Denkrichtung gibt.

Die Unspezifischkeiten und Löcher der Aufgabenstellung müssen erst mal geklärt werden.

Die anschließende Umsetzung, wenn die Bedingungen erst mal hieb- und stichfest formuliert sind, sollte dann nicht mehr sonderlich problematisch sein.

Wenn du nicht jedes Mal beim Erstellen der Abfrage Bedingungen a la WHERE jahr = '2010' OR jahr = '*' zusammenbasteln willst, dann könntest du auch statt dem Sternchen das Zeichen % als Platzhalter für Jahr/Monat beliebig in der Datenbank nutzen; und deine Abfragen dann mit LIKE andersherum machen - WHERE '2010' LIKE jahr matched dann sowohl die Datensätze, in denen das Jahr wirklich '2010' lautet, als auch die, wo nur das Wildcard-Zeichen % drin steht. (Das setzt natürlich einen Character-Datentyp voraus, aber wenn die Datumsangaben eh schon zerhackt werden müssen, bringt INT stattdessen vermutlich auch nicht mehr viele Vorteile. Allerdings musst du dann Monats-/Tages-Angaben konsequent handhaben, was führende Nullen bei einstelligen Werten angeht.)
Zu überlegen (bzw. ggf. zu untersuchen) wäre dann noch, wie sich LIKE von der Performance her zu einem „echten“ Vergleich verhält, und ob da noch Indexe genutzt werden können. Hängt auch vom angestrebten Datenvolumen ab.

MfG ChrisB

--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]