Zeitperioden vergleichen mit MySQL und PHP + Zend Framework

[Alexander, W.]

Hallo Mitdenker,

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

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. Nachfolgend sind nicht angegebene Daten mit Stern gekennzeichnet. Die bedeuten in diesem Fall "jeder" oder "jedes".

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

1 | 05.01.2010 - 10.05.2010
2 | 15.12.2010 - 15.01.2011 (über Silvester)
3 | 10.06.* - 20.09.* (gilt für jedes Jahr)
4 | 10.*.* - 20.*.* (gilt für jeden Monat und jedes Jahr)
5 | 10.*.2010 - 20.*.2010 (gilt für jeden Monat in dem Jahr 2010)
6 | 10.11.* - 30.03.* (über Silvester und jedes Jahr)
7 | 01.09.* - 05.05.* (über Silvester und jedes Jahr)

Nun wird in einem Webformular eine andere beliebige (aber vollständige) Zeitperiode angegeben, zum Beispiel wie folgt:

05.05.2010 - 05.08.2010 (lang)
01.07.2010 - 07.07.2010 (kurz)
23.12.2010 - 04.01.2011 (über Silvester)
…

Es wird eine Formel (oder Algorithmus) gesucht, die alle Perioden (aus der Datenbank) findet, die für (im Webformular) angegebene Periode passend sind. Praktisch also bekommt die Formel bzw. Algorithmus die Periode aus dem Formular und soll in der DB "id’s" finden, die die gesuchte Periode beinhalten können.

Periode : ID
05.05.2010 - 05.08.2010 : keine
01.07.2010 - 07.07.2010 : 3
23.12.2010 - 04.01.2011 : 2, 6, 7

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

Danke im Voraus
Gruß Alexander.

[Bademeister]

Hi.

Ich hab da erstmal ein paar Fragen:

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

3 | 10.06.* - 20.09.* (gilt für jedes Jahr)

Was bedeutet das? Das '*' vorne und hinten müssen dasselbe Jahr sein? Oder können es auch verschiedene Jahre sein (was unsinnig wäre, weil dann der Datensatz auf jedes im Formular eingegebene Datum passen würde, also eher ne rhetorische Frage)?

6 | 10.11.* - 30.03.* (über Silvester und jedes Jahr)

Und das hier gilt dann für jedes '*' vorne und '*+1' hinten? Dass beide * beliebig gewählt werden können, wäre wiederum unsinnig. Wenn ich bis hierhin richtig liege, wirft das aber weitere Fragen auf:

• Dein Datenbankdesign ermöglicht es nicht, einen Zeitraum anzugeben, der sich jährlich wiederholt, aber länger als ein Jahr ist. Ist das so gedacht?

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

• Heißt das hier nun auch, dass die Monate vorne und hinten identisch sein müssen? Oder kann ich auch vorne ne 8 und hinten ne 3 als Monat einfügen und dann wieder die Jahreszahlen wie oben auf etwa 2008 vorne und 2009 hinten setzen?

Du solltest dringend darüber nachdenken, das Design der Datenbank dahingehend zu ändern, dass Du Start- und Enddatum als echtes Datum speicherst, und in einer weiteren Spalte die "Frequenz" der Wiederholung: "monatlich/jährlich/keine Wiederholung". Denn mit Deinem Design müsstest Du erstmal haargenau(!) formulieren, was ein Datensatz überhaupt bedeutet - siehe die obigen Fragen.

Das angeregte Design wäre dabei leichter (weil eindeutig) zu interpretieren, und flexibler, weil die Wiederholungsintervalle nicht das Datenbankdesign beeinflussen - etwa wöchentliche Wiederholungen könnten ohne weiteres eingeführt werden, wenn gewünscht.

Es wird eine Formel (oder Algorithmus) gesucht, die alle Perioden (aus der Datenbank) findet, die für (im Webformular) angegebene Periode passend sind. Praktisch also bekommt die Formel bzw. Algorithmus die Periode aus dem Formular und soll in der DB "id’s" finden, die die gesuchte Periode beinhalten können.

Bei gegebenem Eingebeintervall:

Für jeden Datensatz: Nimm das Startdatum und addiere dazu die maximale Anzahl an Wiederhlungsintervallen (d.h. Monaten/Jahren/..., je nach "Wiederholungsfrequenz"), so dass das Ergebnis kleiner ist als das Startdatum des eingegebenen Intervalls.
Addiere dasselbe Intervall zum Enddatum des Datensatzes und prüfe, ob das Ergebnis größer ist als das Enddatum des Eingabeintervalls:
Ja   => Datensatz wird ausgewählt.
Nein => Datensatz wird nicht ausgewählt.

Für die Implementierung wirst Du es zu schätzen wissen, wenn Du es mit echten Daten zu tun und die Datumsfunktionen des DBMS zu Verfügung hast.

Viele Grüße,
der Bademeister

[ChrisB]

Hi,

Du solltest dringend darüber nachdenken, das Design der Datenbank dahingehend zu ändern, dass Du Start- und Enddatum als echtes Datum speicherst, und in einer weiteren Spalte die "Frequenz" der Wiederholung: "monatlich/jährlich/keine Wiederholung".

Stimmt, „echte“ Datumsangaben wären auf jeden Fall vorzuziehen.

Und auch dabei sind Wildcards für Jahr und Monat nicht besonders schwer umzusetzen - wenn man die Info, ob Jahr/Monat frei sein sollen, in einer zusätzlichen Spalte ablegt. Das könnten bspw. Spalten vom Typ Boolean/Tinyint sein, in die man einfach eine 0 reinschreibt für „ist nicht variabel“ und eine 1 für „variabel“.

Damit kann man sich größeren logischen Aufwand beim dynamischen Generieren der Query ersparen, in dem man einfach Bedingungen in der Art
WHERE (YEAR(datensatzdatum) = '2010' OR yearisvar) AND (MONTH(datensatzdatum) = '07' OR monthisvar)
formuliert - wenn in den Spalten yearisvar/monthisvar jeweils 0 oder 1 drin steht, ist der Kuchen an der Stelle damit schon gegessen.

Das angeregte Design wäre dabei leichter (weil eindeutig) zu interpretieren, und flexibler, weil die Wiederholungsintervalle nicht das Datenbankdesign beeinflussen - etwa wöchentliche Wiederholungen könnten ohne weiteres eingeführt werden, wenn gewünscht.

Nun, die werden nach wie vor etwas mehr Rechenaufwand/Abfragelogik erfordern - oder hast du da schon eine Logik im Sinn, wie das umzusetzen wäre?

Für jeden Datensatz: Nimm das Startdatum und addiere dazu die maximale Anzahl an Wiederhlungsintervallen (d.h. Monaten/Jahren/..., je nach "Wiederholungsfrequenz"), so dass das Ergebnis kleiner ist als das Startdatum des eingegebenen Intervalls.

Soll das innerhalb der Query/in SQL passieren, oder siehst du das als vorgelagerte Logik, die im Script (PHP) untergebracht werden soll?

Für die Implementierung wirst Du es zu schätzen wissen, wenn Du es mit echten Daten zu tun und die Datumsfunktionen des DBMS zu Verfügung hast.

Ja, ich schätze auch.

MfG ChrisB

[Bademeister]

Hi.

Stimmt, „echte“ Datumsangaben wären auf jeden Fall vorzuziehen.

Und auch dabei sind Wildcards für Jahr und Monat nicht besonders schwer umzusetzen - wenn man die Info, ob Jahr/Monat frei sein sollen, in einer zusätzlichen Spalte ablegt. Das könnten bspw. Spalten vom Typ Boolean/Tinyint sein, in die man einfach eine 0 reinschreibt für „ist nicht variabel“ und eine 1 für „variabel“.

Ggf. ja, das wäre dann ein kleines bisschen anders, als ich es im Sinn hatte. Es kommt etwas drauf an, was Alexander genau will. Er hat es (sich) immer noch nicht wirklich klargemacht, was er denn haben will:

• Was ist, wenn ich einen 31.*.* angebe? Wird dann bei Monaten mit < 31 Tagen jeweils der 1. des Folgemonats genommen? Oder sind nur Monate erlaubt, die 31 Tage haben?

• Was ist, wenn ein Intervall vom 31.* bis 31.* geht? Sind dann nur Juli/August und Dezember/Januar als Monate erlaubt? Und wenn nicht, wird dann '31. März bis 31. April' als '31. März bis 1. Mai' interpretiert? Oder bis 30. April? Oder...?

etc. pp.

Wenn man die Anforderung mal *exakt* formuliert - und nicht nur bei jedem Nachfragen halt etwas exakter als vorher - dann ist man wohl im Grunde fast fertig. Aber wem sag ich das, Du hast ja dasselbe geschrieben; das geht eher an den guten Alex...

Das angeregte Design wäre dabei leichter (weil eindeutig) zu interpretieren, und flexibler, weil die Wiederholungsintervalle nicht das Datenbankdesign beeinflussen - etwa wöchentliche Wiederholungen könnten ohne weiteres eingeführt werden, wenn gewünscht.

Nun, die werden nach wie vor etwas mehr Rechenaufwand/Abfragelogik erfordern - oder hast du da schon eine Logik im Sinn, wie das umzusetzen wäre?

Na ja, ist jetzt auch kein Hexenwerk:
Nehmen wir an, wir haben Einheiten (Wochen/Monate/Jahre/etc.) als Intervall im Datensatz (n wäre hier 1, ich würde dazu neigen, algorithmisch erstmal beliebiges n hier zulassen zu wollen).
Dann nimmt man die Anzahl Einheiten der beiden Startdaten (etwa Anzahl Monate seit 1970 oder so), zieht sie voneinander ab, rundet auf ein ganzzahliges Vielfaches von n ab. Und wenn es bereits ein Vielfaches von n ist, muss man noch prüfen, ob man noch n abziehen muss oder nicht.

Die ermittelte Anzahl Einheiten addiert man zum Enddatum des Datensatzes und vergleicht mit dem Enddatum des Eingabeintervalls.

Soll das innerhalb der Query/in SQL passieren, oder siehst du das als vorgelagerte Logik, die im Script (PHP) untergebracht werden soll?

Ich würds in SQL machen. Wird vielleicht ein etwas sperriger Ausdruck, aber ich sehe keine größeren Probleme. Du?

Viele Grüße,
der Bademeister

[Alexander, W.]

Hallo Bademeister,

• Was ist, wenn ich einen 31.*.* angebe? Wird dann bei Monaten mit < 31 Tagen jeweils der 1. des Folgemonats genommen? Oder sind nur Monate erlaubt, die 31 Tage haben?

• Was ist, wenn ein Intervall vom 31.* bis 31.* geht? Sind dann nur Juli/August und Dezember/Januar als Monate erlaubt? Und wenn nicht, wird dann '31. März bis 31. April' als '31. März bis 1. Mai' interpretiert? Oder bis 30. April? Oder...?

etc. pp.

Wenn man die Anforderung mal *exakt* formuliert - und nicht nur bei jedem Nachfragen halt etwas exakter als vorher - dann ist man wohl im Grunde fast fertig. Aber wem sag ich das, Du hast ja dasselbe geschrieben; das geht eher an den guten Alex...

Die Anforderungen sind bereits exact formuliert. Der Rest sind Ausnahmen. 31.*.* ist der 31 und nich der 1. Es wäre unfair mich dazu zu zwingen, alle Ausnahmen einzeln zu beschreiben.

31.*.* bis 31.*.* bedeutet also nur 31-ten Tag eines Monats, der Einen beinhaltet.

Ich habe bereits eine Lösung, an der ich gerade noch arbeite. Dazu schreibe ich später im Blog.

Danke.
Gruß Alexander.

[Bademeister]

Die Anforderungen sind bereits exact formuliert. Der Rest sind Ausnahmen. 31.*.* ist der 31 und nich der 1. Es wäre unfair mich dazu zu zwingen, alle Ausnahmen einzeln zu beschreiben.

Sorry, wenn meine Bemerkung oben etwas abwertend klang, das war nicht so gedacht. Aber zum Finden eines Algorithmus spielt es schon eine große Rolle, was der denn genau leisten soll. Insbesondere ist die Frage, ob die Datumsfunktionen von MySQL (etwa adddate) hilfreich sind und etwas für Dich Brauchbares tun, ein Aspekt bei der Frage des genauen Datenbankdesigns.

31.*.* bis 31.*.* bedeutet also nur 31-ten Tag eines Monats, der Einen beinhaltet.

Ach so, erste Frage wäre überhaupt: Ist das ein Intervall von einem Monat oder einem Tag, sprich: sind die Monate der beiden Daten als identisch anzunehmen, wenn die Tage gleich sind? Nach all dem Beschriebenen denke ich: ja, dann hab ich in meinem obigen Post da falsch gelegen.

Ich hätte aber noch mal ne Frage, weils mich interessiert: Wozu dient denn das Ganze? Da ja die verschobenen Intervalle nicht mal gleich lang sind (etwa 15.1. - 10.2. ist größer als 15.2. - 10.3.), hab ich nicht so recht ne Idee, was Du damit überhaupt tust.

Ich habe bereits eine Lösung, an der ich gerade noch arbeite. Dazu schreibe ich später im Blog.

Ok. Wo findet man das dann?

Viele Grüße,
der Bademeister

[Alexander, W.]

Hallo Bademeister,

Wozu dient denn das Ganze?

Die Verfügbarkeit der Mietobjekte soll von einem Vermieter beschränkt werden. Dazu werden Saisonperioden angelegt, die einem Mietobjekt zugewiesen werden. Anhand von diesen Perioden kann der Suchalgorithmus entscheiden, ob ein Mietobjekt in einem konkreten gesuchten Zeitraum verfügbar ist. Mein Ziel ist es die Definition von Saisonperioden möglichst flexibel zu implementieren.

Ok. Wo findet man das dann?

Auf meiner Seite im Forum / Blog: http://www.booking-monitor.com/forum/ ...in wenigen Tagen.

Gruß Alexander.

[Alexander, W.]

Hallo Bademeister,

die Aufgabenstellung habe ich im folgenden Post konkretisiert:
http://forum.de.selfhtml.org/my/?t=199054&m=1338104

Gruß Alexander.

[ChrisB]

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

[dedlfix]

Hi!

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.

Ich hatte gerade keine Probleme, 00 und 0000 als Tag, Monat und Jahr in jeweils beliebiger Anzahl (und damit auch Kombination) innerhalb eines Datums (DATE) einzubauen. Solche ungültigen Werte verhindern allerdings effektiv das Rechnen mit dem Datum, wenn man nicht ständig vorher Prüfungen darauf einbaut.

Lo!

[Alexander, W.]

Hallo Chris,

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.

Ich bin an das DB-Design nicht gebunden und kann (wenn überzeugt) eine andere Variante wählen. Gern auch die mit "varmonth" und "varyear" Spalten. Da im Moment die Berechnung mit Daten innerhalb von DB nicht möglich scheint, halte ich die aktuelle Speicherung für sinnvoll bzw. nutzbar. Ob man eine Jahreszahl mit "YEAR()" oder direkt über "begin_year" bekommt spielt im Moment keine Rolle.

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.?

Hier bin ich mit meiner Beschreibung in der Tat nicht vollständig gewesen. Das * soll folgendermaßen interpretiert werden:

Jahr = *, dann ist Jahr normalerweise an beiden Stellen gleich. Vorausgesetzt die Periode lässt sich gültig auf ein Jahr anwenden. D.h. wenn man das selbe Jahr "angenommen" hat, soll "begin" VOR dem "end" liegen. Ist dies nicht der Fall, dann ist das Endjahr (über Silvester) um 1 größer als Anfangsjahr bzw. Anfangsjahr um 1 kleiner als das Endjahr. Das gleiche gilt für die Monate.

GENERELL lautet die Regel folgendermaßen: die Sternchen sind so zu ersetzen, dass eine möglichst kleine Zeitperiode entsteht.

4 | 10.*.* - 20.*.* = 10 bis 20 April, 10 bis 20 Mai, 10 bis 20 Juni eines Jahres.

Wenn man jedoch

8 | 20.*.* - 10.*.* anwendet, dann sieht die Sache ganz anderes aus: 20 bis 10 Juni eines Jahres .... 20 Dezember bis 10 Januar (+ 1 Jahr) - 20.12.2010 bis 10.01.2011.

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

Zurzeit berechne ich alles in PHP, was diese Aufgabe angeht. D.h. eine Periode wird über die andere "geschoben" und Daten verglichen. Die Funktion ist jedoch verbugt und liefert nicht immer korrekte Ergebnisse. Um die 10x oder 100x "if's" zu ersparen suche ich eine generelle Lösung.

Ich bedanke mich für das Mitdenken.

Gruß Alexander.

[Alexander, W.]

Hallo Mitdenker,

ich kann stolz sagen, dass ich die Lösung gefunden und umgesetzt habe. Bis auf einige futuristische Ausnahmen funktioniert die Suche der Perioden ganz prima. Um die Tests besser durchführen zu können habe ich ein Testskript geschrieben, welches unter folgendem Link erreichbar ist:

http://devel.booking-monitor.com/booking-monitor/tests/period-search.php

Wie man es schön sagt "Ein Kopf ist gut, zwei sind besser". Genau aus diesem Grund bitte ich alle, die es nicht zu eilig haben mir beim Testen zu helfen und gefundene Fehler zu posten.

Danke im Voraus.
Gruß Alexander.

@Shadowcrow, Bitte um Hinweis auf die Richtlinien, die meinen anderen Posting als Doppelposting einstufen.

[Texter mit x]

@Shadowcrow, Bitte um Hinweis auf die Richtlinien, die meinen anderen Posting als Doppelposting einstufen.

Du hast angegeben die Charta gelesen zu haben, dann tu das doch auch.

[Shadowcrow]

'ǝɯɐu$ ıɥ

@Shadowcrow, Bitte um Hinweis auf die Richtlinien, die meinen anderen Posting als Doppelposting einstufen.

Kommt sofort:
http://forum.de.selfhtml.org/hilfe/charta.htm
http://forum.de.selfhtml.org/hilfe/charta.htm#keine-doppelpostings

Zur Mail:
Threadtitel werden im Nachhinein nicht mehr verändert (weiß nicht ob Mods das könnten), du kannst aber bei einen neuen Post jederzeit den Titel/Themenbereich anpassen (wie ich es gerade getan habe).
Du bestätigst bei jedem Post die Charta gelesen zu haben weißt aber nicht wo du sie findest? Tzk :-)
Mir bezüglich des Forums eine Mail zu schreiben ist nicht wirklich zielführend, ich bin nur ein Teilnehmer, kein Mod, du hättest mich bzw. die anderen auch in einem Posting ansprechen können (hast du ja tlw. auch getan).

ssnɹƃ
ʍopɐɥs

[Der Martin]

Hallo Alexander[*],

@Shadowcrow, Bitte um Hinweis auf die Richtlinien, die meinen anderen Posting als Doppelposting einstufen.
Kommt sofort:
http://forum.de.selfhtml.org/hilfe/charta.htm
http://forum.de.selfhtml.org/hilfe/charta.htm#keine-doppelpostings

ja, richtig. Da steht zwar nichts drin, was den neuen Beitrag nun explizit und unumstößlich als Doppelposting einstuft, aber hier passt in etwa der Absatz "Oder es stehen im Doppelposting sogar noch weniger Informationen drin ..."

Nach meinem Eindruck war's ein Resumée des bisherigen Threads, kombiniert mit einer weiterführenden Frage. Sowas gehört auf jeden Fall zum bestehenden Thread, nicht in einen neuen.

Zur Mail:

Es ist von den meisten Forumsteilnehmern nicht erwünscht, Follow-ups direkt per Mail zu bekommen. Wenn es etwas zu fragen gibt, ist das Forum hier der richtige Ort. Gut, in diesem Fall habe ich den Thread gesperrt, so dass *dort* keine Antwort mehr möglich war; hier im Originalthread wäre die Rückfrage aber auch gut aufgehoben gewesen. Deswegen ... naja, du hast eine Kontaktmöglichkeit gesucht und eine gefunden, okay.

Threadtitel werden im Nachhinein nicht mehr verändert (weiß nicht ob Mods das könnten)

Nein, können sie nicht.

du kannst aber bei einen neuen Post jederzeit den Titel/Themenbereich anpassen (wie ich es gerade getan habe).

Genau. Und wie das geht, ist auch in der Hilfe zum Forum beschrieben, die im Kopf der Forumshauptdatei verlinkt ist.

Einen schönen Sommertag noch,
 Martin

[*] ja, mir ist bewusst, dass ich technisch gesehen auf Shadowcrow antworte, ich wollte aber beide Beiträge gemeinsam im Zitat haben.

[Alexander, W.]

Hallo Shadowcrow, Hallo Martin,

danke. Ich habe die Hinweise zur Kenntnis genommen.

Ich bin davon ausgegangen, dass mein Posting von Shadowcrow als Doppelposting markiert wurde und ebenfalls von ihm gesperrt wurde. Deswegen habe ich direkt zu ihm Kontakt aufgenommen.

Gruß Alexander.

P.S. Soll ich die Hoffnung auf die Antworten zum eigentlichen Thema aufgeben?

[Der Martin]

Hallo,

Ich bin davon ausgegangen, dass mein Posting von Shadowcrow als Doppelposting markiert wurde und ebenfalls von ihm gesperrt wurde. Deswegen habe ich direkt zu ihm Kontakt aufgenommen.

nein, sie hat es nur markiert, so bin ich schneller darauf aufmerksam geworden. ;-)

P.S. Soll ich die Hoffnung auf die Antworten zum eigentlichen Thema aufgeben?

Nein. Aber dein Problem scheint mir sehr speziell zu sein, und wie es aussieht, ist das Interesse hier gering. Aber auch nach zwei, drei Tagen könnte immer noch jemand vorbeikommen, der "zufällig" etwas Hilfreiches sagen kann. Allzugroße Resonanz würde ich an deiner Stelle aber auch nicht mehr erwarten.

Ciao,
 Martin

[Bademeister]

Hi.

P.S. Soll ich die Hoffnung auf die Antworten zum eigentlichen Thema aufgeben?

Hi. Da ich zu Beginn schon mitdiskutiert habe, hab ich jetzt auch mal ein bisschen rumgespielt. Hier mal meine ersten Eindruecke:

• Das 'Design' gefaellt mir sehr gut: schlicht, uebersichtlich, gut lesbar, ohne langweilig zu wirken. Ist eigentlich kein wesentlicher Aspekt bei einer funktionalen Testseite, aber ich wollt's mal gesagt haben.

• Der Eindruck ist, dass die Abfragen recht lange dauern. Das erstmal so als Feststellung, ob man es schneller hinbekommen kann, weiss ich natuerlich derzeit nicht.

• Ich habe natuerlich gleich mal die von mir bereits thematisierte Frage mit den 31. des Monats ausprobiert. Fuer die Periode

'31. * * - 13. * *' // <-- da fehlen uebrigens zwei Punkte, denke ich

bekomme ich als Antwort:

'Periode 9 Jul 2010 - 11 Jul 2010 - ja'

d.h. der Monat wird hier beim Vergleich als Jun/Jul (31.6. - 13.7.) angenommen, obwohl der Juni keinen 31. hat. Wenn das so gedacht ist, was ist dann der Unterschied zwischen '31.' und 'Monatsende' bei der Tagesangabe? Das Monatsende-Ding, das ich schon trotz vorheriger Diskussion hier nicht ganz verstehe, bedarf auf jeden Fall einer Erlaeuterung auf der Seite, finde ich.

• Wieso ist eine Wiederholung bei der Eingabe der Periode notwendig? Wenn ich nur eine konkrete Periode testen will, werde ich mit einer Liste von (standardmaessig) 1000 Antworten erschlagen und muss ca. 2,5 Sekunden auf mein Ergebnis warten, von dem mich (standardmaessig) 999‰ nicht interessieren.

Das mal so als meine Eindruecke/Anregungen.

Viele Gruesse,
der Bademeister

[Alexander, W.]

Hallo,

• Das 'Design' gefaellt mir sehr gut: schlicht, uebersichtlich, gut lesbar, ohne langweilig zu wirken. Ist eigentlich kein wesentlicher Aspekt bei einer funktionalen Testseite, aber ich wollt's mal gesagt haben.

Danke!

• Der Eindruck ist, dass die Abfragen recht lange dauern. Das erstmal so als Feststellung, ob man es schneller hinbekommen kann, weiss ich natuerlich derzeit nicht.

Zum Testen werden 1000 Perioden genommen, wobei man die Zahl auch reduzieren kann. Für die 1000 braucht das Skript ca. 2 evtl. 2,5 Sekunden. Das ist ziemlich viel und ich hoffe, ich finde noch Stellen, wo ich optimieren kann.

• Ich habe natuerlich gleich mal die von mir bereits thematisierte Frage mit den 31. des Monats ausprobiert. Fuer die Periode

'31. * * - 13. * *' // <-- da fehlen uebrigens zwei Punkte, denke ich

Solange der Monat und Jahr angegeben ist, dann sieht das folgendermaßen aus: "31. Januar 2010". Nun bin ich mir nicht sicher ob bei fehlenden Daten die Punkte dort stehen müssen. Die Frage habe ich mir auch schon gestellt und habe leider noch keine eindeutige Antwort. Vermutlich sieht "31.*.*" verständlicher aus als "31.* *".

'Periode 9 Jul 2010 - 11 Jul 2010 - ja'

d.h. der Monat wird hier beim Vergleich als Jun/Jul (31.6. - 13.7.) angenommen, obwohl der Juni keinen 31. hat. Wenn das so gedacht ist, was ist dann der Unterschied zwischen '31.' und 'Monatsende' bei der Tagesangabe? Das Monatsende-Ding, das ich schon trotz vorheriger Diskussion hier nicht ganz verstehe, bedarf auf jeden Fall einer Erlaeuterung auf der Seite, finde ich.

Monatsende macht Sinn bei Perioden wie z.B. "20. Februar * - Monatsende. Februar  *", obwohl "20. Februar * - 31. Februar *" das Gleiche macht. Der User soll nicht dazu gezwungen werden 31 für alle Monate zu wählen, weil es für alle Monat nicht zutrifft.

Ungelöst ist leider noch Suche in der Periode "Monatsende. * * - 30. * *". Da sucht es mal vom 31.07 bis 30.08 und mal vom 30.06 bis 30.06. Im ersten Fall über ein Monat, im zweiten Fall nur an einem Tag. Darüber mache ich mir gerade noch Gedanken ^^.

• Wieso ist eine Wiederholung bei der Eingabe der Periode notwendig? Wenn ich nur eine konkrete Periode testen will, werde ich mit einer Liste von (standardmaessig) 1000 Antworten erschlagen und muss ca. 2,5 Sekunden auf mein Ergebnis warten, von dem mich (standardmaessig) 999‰ nicht interessieren.

Ich habe die standardmäßige Zahl auf 400 reduziert. Die Wiederholungen sollen die Fehlersuche vereinfachen. So kann man gleich mehrere Daten testen und die Zeit messen.

Wenn der Enduser (Mieter) nach freuen Objekten sucht (z.B. Unterkunft für 7 Tage in einem Monat Urlaubszeit), dann gibt er im Suchformular vom 01.08.2010 bis 31.08.2010 und 7 Tage. Die Suche startet mit 01.08 - 08.08 und testet jede Periode bis 31.08. In diesem Formular ist die Eingabe ähnlich nur mehr für Tests gedacht.

Gruß Alexander.

[Texter mit x]

P.S. Soll ich die Hoffnung auf die Antworten zum eigentlichen Thema aufgeben?

Frühestens in wenigen Tagen +x.