ich sitze grade an einem kleinen Newsscript für die neue Version meiner Website (werde bis morgen wohl nicht fertig sein )
Dabei möchte ich, dass nur Beiträge der letzten 2 Monate angezeigt werden.
Das Datum des eintrags ist als timestamp in der Datenbank gespeichert.
hier mein bisheriger Code, der leider nicht funktioniert:
$maxNewsTime = time() - 62*24*60*60;
$sql = "SELECT * FROM `news` WHERE `date` > " . $maxNewsTime;
$query = mysql_query($sql);
Unix Timestamps in einer MySQL-Datenbank zu benutzen, ist i.a.R. suboptimal.
Nutze einen der Datumstypen, den MySQL dir bereitstellt - dann kannst du darauf auch komfortabel mit den Datumsfunktionen von MySQL arbeiten. Im konkreten Falle hilft dir dann bspw. DATE_SUB sehr leicht weiter.
Und das gewoehne dir bitte ganz ab - “funzt nich” ist absolut keine brauchbare Problembeschreibung.
anders gesagt, datentyp ist TIMESTAMP, im Format ‘YYYY-MM-DD HH:II:SS’
Sorry, aber es gibt kein andres Problem als das es nicht funktioniert.
Welcher andere Datentyp wäre denn besser (sollte automatisch bei INSERT und UPDATE gesetzt weden)?
für solche scripts sollte man lieber das, was man in php unter timestamp (time()) versteht nehmen, in Mysql hiesse das dann INT (15)…
dann kannst du ganz einfach beim SELECT befehl dieses hier hinzufügen: " WHERE timestamp_feld > ‘". $bestimmter_zeitraum ."’"
die variabel bestimmter_zeitraum musst du dann halt noch errechnen…
Na ja, wenn du einen MySQL TIMESTAMP als Feldtyp verwendest, dann ist es ja auch unsinnig, diesen mit einem Unix Timestamp, wie PHPs time() ihn liefert, vergleichen zu wollen.
Mach dir bitte erst mal den Unterschied klar … und dann schau dir die Funktion an, die ich nannte.
Nein, das sollte man eben nicht.
Fuer zahlreiche Operationen, die man mit so einem Datum auf der Datenbank machen moechte (Selektion nach bestimmtem Zeitraum, Gruppierung ueber Monat/Jahr, etc.), ist das native Datumsformat der Datenbank besser geeignet.
Wenn man dann beim Anzeigen der Daten diese in PHP mittels strftime() o.ae. nach lokalenEinstellungen formatieren moechte - dann kann man sich beim Auslesen der Daten das ganze von MySQL immer noch als Unix Timestamp liefern lassen.
Die bekomme ich mit noch weniger Code:
SELECT * FROM tabelle WHERE YEAR(datum) = ‘2008’
Und wie machst du das mit deinem Unix Timestamp, wenn du beispielsweise die Eintraege nach Jahr und Monat gruppieren willst, um die Anzahl Eintraege je Monat zu ermitteln …?
Das ist immer noch suboptimal, weil du das Vergleichsdatum erst in PHP „vorbereiten“ musst.
Die Datenbank kennt das aktuelle Datum, und kann davon auch zwei Monate abziehen - also keine Notwendigkeit, da mit PHP irgendeine Vorarbeit zu leisten.
Jaja, ist ja schon gut. Ich bin nunmal besser in PHP als in SQL, von daher passt mir michis Variante schon besser.
Und was die efizienz angeht: die 1000 besucher täglich werden vorerst wohl auch ausbleiben
Verstehe ich jetzt nicht? Warum sollte ‚2009-02-28 20:00:00‘ kleiner sein als ‚2009-02-28T17:33:49+01:00‘? Schliesslich liegt ersteres weiter in vom 1.1.70 entfernt, und müsste damit doch größer sein…
OK, frage ich anders^^ Was muss denn jetzt schreiben, um keine Beiträge aus der Zukunft zu holen, und keine, die älter als 2 Monate sind?
WHERE `datum` > DATE_SUB(NOW(), INTERVAL 2 MONTH)
AND `datum` <= NOW()
datum muss größer als Heute minus 2 Monate sein
und kleiner (oder gleich) Heute.
Das sind keine Zahlen, sondern Strings. Und also solche werden sie auch verglichen.
Die ersten paar Stellen sind bei beiden gleich, dann kommen wir zu der Stelle, wo im ersten String ein Leerzeichen, und im zweiten ein ‘T’ steht. Das Leerzeichen liegt auf einer niedrigeren (ASCII-)Position als das T, und demzufolge wird der erste String als “kleiner” betrachtet.
Vor allem solltest du von Anfang an beruecksichtigen, was dir bereits ganz zu Beginn dieser Diskussion gesagt wurde:
Ich war davon ausgegangen, das ie MySQL-Engine die Strings als Daten (was ist die Mehrzahl von Datum???) erkennt, und danach auch vergleicht.
So ist das logisch, aber wen man von obigem ausgeht, nicht so leicht verständlich.
bzgl. DATE_SUB:
Ich benutze es ja jetzt, nur bin ich noch kein SQL-Profi, und da ich von obigem ausgegeangen war, erschien das für mich dann einfacher, und daher für mich sinnvoller.
)
Was muss denn jetzt schreiben, um keine Beiträge aus der Zukunft zu holen, und keine, die älter als 2 Monate sind? 
