Timestamp vom Anfang der Woche/des Monats?

[WauWau]

Hallo Sven,

Ich finde es spannend, dass bei Datumsrechnerei jeder sofort an irgendwelche komplexen Rechnereien in PHP denkt, aber niemand die Datumsrechnungsfunktionen von MySQL berücksichtigt.

na gut, das ganze mit MySQL zu machen, wäre auch eine Idee. Aber erstens mal wird es letztenendes nicht wirklich einfacher, und zweitens ... gefallen mir die "Date"-Felder von MySQL nicht wirklich. Die sind irgendwie hässlich, diese Speicherungsteile, und dementsprechend - was liegt näher als einfach simpel einen PHP-Timestamp (meinetwegen auch "Unix-Timestamp") zu speichern, mit dem man dann in PHP ganz gemütlich rumbasteln kann, als irgendwelche mühseligen Umwandlungsfunktionen MySQL-"Timestamp"<=>Unix-Timestamp (auf dem Online-Manual bei php.net haben einige Leute was ganz brauchbares gepostet...) jedes mal auszuführen...

Ich meine, wo ist der Unterschied, ob ich eine MySQL-Abfrage etwa so mache:...
  "SELECT * FROM news WHERE date > $x ORDER BY date DESC, id"
und $x ist hierbei ein simpler PHP-Timestamp von gestern (ist in diesem Zusammenhang irrelevant)... oder wenn ich so was schreibe wie
  "SELECT * FROM news WHERE TO_DAYS(date) >= ... "
und dabei dann irgendwelche speziellen mySQL-Funktionen benutze. Mein Syntax oben hat zum einen den Vorteil, dass ich ganz simpel einfach für $x irgendeinen Timestamp einsetzten kann, wobei ich bei irgendwelchen mySQL-Funktionen mir erst mal den MySQL-Syntax zusammenbasteln darf.

Ach ja, und zudem möchte ich meinen Abfragesyntax eigentlich auch noch kompatibel halten, also ich meine, es könnte ja vorkommen, dass ich urplötzlich auf ODBC oder sowas angewiesen bin (obwohl das afaik auch so eine art SQL-Syntax benutzt, aber ... keine ahnung).

Zuerst einmal: Diese Funktionen sind am wirkungsvollsten, wenn man in MySQL keinen Unix-Timestamp in ein Integerfeld speichert, sondern eine Spalte vom typ DATETIME (wenn man die Uhrzeit benötigt) oder DATE anlegt.

Hmm, und dann nochmal vom ganz theoretischen angesehen... Ein Unix-Timestamp, der 11 Ziffern beinhaltet (also ein normaler "INT"), nimmt doch weiniger speicher weg als "YYYYMMDDHHMMSS", also 14 Zeichen des Types "INT" oder meinetwegen auch "DATE"....

Und dann sind gewisse Operationen relativ simpel.

Vergleichen wir mal:

SELECT * FROM tab WHERE TO_DAYS(datumspalte) >= TO_DAYS(CONCAT(YEAR(NOW()),"-",MONTH(NOW()),"-01"))

"SELECT * FROM news WHERE date > ".mktime(0,0,0,date("m"),date("j")-date("w"),date("Y"));

und, was ist letztenendes "einfacher"? Hmmm, ich finde mein Beispielchen übersichtlicher, da man sofort erkennt, welchen Timestamp mktime() zurückliefert [afaik mktime(sec,min,stund,monat,tag,jahr,sommer/winter)], und keine komischen MySQL-Funktionen anwendet.

SELECT * FROM tab WHERE YEAR(datumspalte) = YEAR(NOW()) AND MONTH(datumspalte) = MONTH(NOW())

ok, sooo kompliziert sieht es nicht aus, aber irgendwie gefällt mir meine Lösung besser (->[pref:t=78175&m=451870])...

Zusammenfassen könnte man das auch, indem man datumspalte und NOW() als formatiertes Datum nur mit Jahr und Monat ausgibt und als String vergleicht. Ist die Frage, was performanter ist.

hmm, ja, ist auch die Frage, ob PHP das mit seinen Timestamps nicht auch recht schnell hinbekommt... Also ob diese MySQL-Funktionen oben, wo doch MySQL mit strings und sowas rumhantieren müssen, letztenendes mit sowas "SELECT * FROM tab WHERE datumspalte < 12345678901 AND datumsspalte > 12345678900" vergleichbar ist.

Die Geschichte mit dem Wochenanfang ließe sich mit DAYOFWEEK() und DATE_SUB() bzw. DATE_ADD() regeln - also die Differenz des DAYOFWEEK() des aktuellen Tages zum Montag oder Sonntag (1 oder 2) errechnen und von aktuellen Datum abziehen.

also letztenendes auch wieder gerechne. Welches Programm dieses Gerechne anstellt, spielt doch keine wirklich große rolle, oder?

WauWau