Vorherige und nächste Nachricht anzeigen

[Fritz]

Hallo,

bei der Ausgabe meiner News würde ich gerne als Spielerei die letzte und die nächste Nachricht anzeigen lassen, sortiert nach dem Datum (date-Format).

Beispiel: Ausgegeben wird die Nachricht

Fritz hat keine Probleme vom 10.7.2010

Unter dieser Nachricht soll die letzte ausgegeben werden, z. B.

Hat Fritz Probleme? vom 9.7.2010

sowie

Warum Fritz keine Probleme hat vom 11.7.2010.

Ich bin noch etwas neu in der "Szene" und erst am Anfang mit Php und Mysql (darin sind meine Nachrichten gespeichert).

Für Tipps und konkrete Code-Schnipsel wäre ich sehr dankbar!

[Fred Furunkelstein]

Für Tipps und konkrete Code-Schnipsel wäre ich sehr dankbar!

Tach! Post!

Das Handbuch sagt:

"UNION wird verwendet, um das Ergebnis einer Anzahl von SELECT-Anweisungen zu einer Ergebnismenge zusammenzufassen."

Code-Schnipsel:

(  
    (SELECT `nachricht` FROM `nachrichten` where `id` < 100 ORDER BY `id` LIMIT 1)  
[link:http://dev.mysql.com/doc/refman/5.1/de/union.html@title=UNION]  
    (SELECT `nachricht` FROM `nachrichten` where `id` = 100)  
[link:http://dev.mysql.com/doc/refman/5.1/de/union.html@title=UNION]  
    (SELECT `nachricht` FROM `nachrichten` where `id` > 100 ORDER BY `id` DESC LIMIT 1)  
) ORDER BY `id`;

oder:

(  
    (SELECT `nachricht` FROM `nachrichten` where `id` <= 100 ORDER BY `id` LIMIT 2)  
[link:http://dev.mysql.com/doc/refman/5.1/de/union.html@title=UNION]  
    (SELECT `nachricht` FROM `nachrichten` where `id` > 100 ORDER BY `id` DESC LIMIT 1)  
) ORDER BY `id`;

Fred

[ChrisB]

Hi,

(

(SELECT nachricht FROM nachrichten where id < 100 ORDER BY id LIMIT 1)
[link:http://dev.mysql.com/doc/refman/5.1/de/union.html@title=UNION]
    (SELECT nachricht FROM nachrichten where id = 100)
[link:http://dev.mysql.com/doc/refman/5.1/de/union.html@title=UNION]
    (SELECT nachricht FROM nachrichten where id > 100 ORDER BY id DESC LIMIT 1)
) ORDER BY id;

  
Vom Prinzip her ja.  
Allerdings sollte die ID bekanntlich nicht als (primäres) Sortierkriterium herhalten, und der OP hatte ja auch explizit nach einer Sortierung nach dem Datum gefragt.  
  
Wenn man das Datum bereits als Suchkriterium vorliegen hat, dann ist es simpel, dann müsste in deinem Vorschlag nur ID jeweils durch die Datumsspalte ersetzt werden.  
  
Wenn jedoch von der vorliegenden ID einer Nachricht ausgehend die jeweils vorherige und nächste gesucht werden sollen, dann müsste man das Datum zu dieser ID ggf. erst noch mit einem Subselect ermitteln.  
  
  
Des weiteren bietet es sich m.E. noch an, innerhalb der einzelnen SELECTs noch ein Kennzeichen zu setzen, an welchem in der Verarbeitung leicht erkennbar ist, um welchen Datensatz es sich denn nun handelt – etwa so,  
~~~sql
(  
  (SELECT …, 'previous' AS position FROM …)  
UNION  
  (SELECT …, 'current' FROM …)  
UNION  
  (SELECT …, 'next' FROM …)  
) ORDER BY …

Das macht es anschließend einfacher, zu erkennen um „welche“ Nachricht es sich beim jeweiligen Datensatz handelt. Denn ein vorheriger/nächster müssen ja nicht unbedingt vorhanden sein – und welcher Fall tatsächlich vorliegt „von Hand“ anhand der Datumsangaben erst ermitteln zu müssen o.ä. wäre eher unschön.

MfG ChrisB

[Fred Furunkelstein]

TachTach

Vom Prinzip her ja.

Vom Prinzip her war mir primär nur wichtig das UNION-Statement zu zeigen.

Allerdings sollte die ID bekanntlich nicht als (primäres) Sortierkriterium herhalten, und der OP hatte ja auch explizit nach einer Sortierung nach dem Datum gefragt.

Andererseits sollte eine inkrementelle ID auch die Reihenfolge des Eingangs der Nachrichten abbilden. Ob das in der Sache korrekt ist mag der Fritz anhand des ihm konkret liegenden Sachverhaltes entscheiden. Freilich kann er das Datum nehmen - ich fürchte aber, es können selbst zu einem in Sekunden aufgelösten Zeitpunkt auch zwei (und mehr!) Nachrichten eingehen. Er will aber immer genau eine Antwort. Damit ist es nicht richtig das Datum als Kriterium zu verwenden.

In meinem Code war aber vor allem ein anderer Fehler:
Neben der Nachricht muss auch die ID selektiert werden, wenn außerhalb der Klammer nach dieser sortiert wird. Das beträfe auch das Datum - allerdings würde diese Sortierung wegfallen wenn Dein nächster Vorschlag umgesetzt wird:

Des weiteren bietet es sich m.E. noch an, innerhalb der einzelnen SELECTs noch ein Kennzeichen zu setzen, an welchem in der Verarbeitung leicht erkennbar ist, um welchen Datensatz es sich denn nun handelt – etwa so,

Die Idee finde ich richtig gut. Das erspart in den Fällen, das weniger als 3 Nachrichten zurück geliefert werden einige Betrachtungen (und damit Programmieraufwand) darüber, welche denn nun nicht existieren.

Fred

[Fritz]

Danke auch noch einmal für Deine Antworten!

Da ich - wie Ihr vermutlich erwartet habt - weder den Spiegel noch die Tagesschau betreue, sind die Datumsvarianten immer eindeutig - mehr als eine Nachricht pro Tag gibt es nicht.

Ich hatte noch keine Zeit zur Anwendung, hoffe aber, dass ich das hinbekomme. Viele Dinge hören sich für mich noch an wie Böhmische Dörfer, wird aber schon...

[Tom]

Hello,

Da ich - wie Ihr vermutlich erwartet habt - weder den Spiegel noch die Tagesschau betreue, sind die Datumsvarianten immer eindeutig - mehr als eine Nachricht pro Tag gibt es nicht.

Das lässt sich ändern ;-P

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Allerdings sollte die ID bekanntlich nicht als (primäres) Sortierkriterium herhalten, und der OP hatte ja auch explizit nach einer Sortierung nach dem Datum gefragt.
Andererseits sollte eine inkrementelle ID auch die Reihenfolge des Eingangs der Nachrichten abbilden. Ob das in der Sache korrekt ist mag der Fritz anhand des ihm konkret liegenden Sachverhaltes entscheiden. Freilich kann er das Datum nehmen - ich fürchte aber, es können selbst zu einem in Sekunden aufgelösten Zeitpunkt auch zwei (und mehr!) Nachrichten eingehen. Er will aber immer genau eine Antwort. Damit ist es nicht richtig das Datum als Kriterium zu verwenden.

Mal angenommen, es kommen pro Sekunde mehrere Datensätze, dann sollte man sich fragen, ob dann eine sekundenfeine Auflösung ausreichend ist oder man nicht lieber Milli- oder Mikrosekunden nimmt. Wenn nur sehr selten mit mehreren Ereignissen pro Sekunde zu rechnen ist und es nicht darauf ankommt, welches von beiden nun tatsächlich eher war, man aber gern eine stets gleiche Reihenfolge haben möchte, kann man als Zweitkriterium die ID nehmen. Aber auf die ID als alleiniges Sortierkriterium sollte man nicht bauen.

Da er - wie nun bekannt ist - die Nachrichten selbst schreibt, würde ich einfach nur Datum mit sekundenfeiner Uhrzeit nehmen. Dann kann er bedenkenlos auch mal zwei oder mehr Nachrichten pro Tag schreiben. Das bisschen mehr Speicher gegenüber einem Nur-Datum fällt nicht ins Gewicht und er ist trotzdem gerüstet auf das was möglicherweise in der Zukunft kommen mag.

Lo!

[Fred Furunkelstein]

Da er - wie nun bekannt ist - die Nachrichten selbst schreibt, würde ich einfach nur Datum mit sekundenfeiner Uhrzeit nehmen.

Der von Dir gezeigte Pragmatismus spricht dann aber auch dafür kurzerhand die ID zu nehmen - welche die Eingangreihenfolge ja (hoffentlich) abbildet. Es erscheint wenig sinnvoll zu sagen, diese oder jene pragmatische Lösung sei falsch weil die Theorie dies und jenes besagt und dann (ganz pragmatisch) selbst eine theoretisch falsche Lösung zu propagieren. Du wirst nicht bestreiten, dass Du genau das getan hast? Oder?

Und nun hör schon auf: Du bist doch genug gelobt worden.

Fred

[dedlfix]

Hi!

Da er - wie nun bekannt ist - die Nachrichten selbst schreibt, würde ich einfach nur Datum mit sekundenfeiner Uhrzeit nehmen.
Der von Dir gezeigte Pragmatismus spricht dann aber auch dafür kurzerhand die ID zu nehmen - welche die Eingangreihenfolge ja (hoffentlich) abbildet.

Das Problem ist das "hoffentlich". Niemand garantiert, dass das immer so ist. Nachher kommt noch jemand auf die Idee, Lücken zu füllen ...

Es erscheint wenig sinnvoll zu sagen, diese oder jene pragmatische Lösung sei falsch weil die Theorie dies und jenes besagt und dann (ganz pragmatisch) selbst eine theoretisch falsche Lösung zu propagieren. Du wirst nicht bestreiten, dass Du genau das getan hast? Oder?

Jein, ich denke, die Qualität ist eine andere, wenn man von einer verlässlichen Uhrzeit ausgeht. Dann kommt die "falsche" Lösung nur in Ausnahmefällen zum Tragen.

Lo!

[Fred Furunkelstein]

Du:

Da er - wie nun bekannt ist - die Nachrichten selbst schreibt, würde ich einfach nur Datum mit sekundenfeiner Uhrzeit nehmen.

Ich:

Der von Dir gezeigte Pragmatismus spricht dann aber auch dafür kurzerhand die ID zu nehmen - welche die Eingangreihenfolge ja (hoffentlich) abbildet.

Du:

Das Problem ist das "hoffentlich". Niemand garantiert, dass das immer so ist. Nachher kommt noch jemand auf die Idee, Lücken zu füllen ...

Ich sehe eine Kreisdiskussion. Du setzt Prämissen an, die zwar für Deine eigene "Lösung" gelten sollen, aber nicht gelten sollen, wenn Du die andere Lösung als "falscher als die Deine" darstellst.

Hier die von Dir nur für Dich gesetzte Prämisse:

Da er - wie nun bekannt ist - die Nachrichten selbst schreibt,

Und hier deren Aufhebung:

Niemand garantiert, dass das immer so ist. Nachher kommt noch jemand auf die Idee, Lücken zu füllen ...

Wer sollte denn der "jemand" sein? Überleg mal!
Alles klar?

Fred

[dedlfix]

Hi!

Alles klar?

Nein, anscheinend nicht, denn wir haben hier zwei Diskussionsgegenstände. Der eine ist die generelle Vorgehensweise, der andere ist der konkrete Vorschlag für den Fall des OP. Im Falle des OP wird es das Problem der mehrfachen Ereignisse zu einen bestimmten Zeitpunkt nicht geben, im Allgemeinen muss man das jedoch in Betracht ziehen. Wenn ich also Wege für den Umgang mit Dopplungen aufzeige, dann um des allgemeinen Gedankenaustauschs wegen, den OP berührt das beim jetzigen Kenntnisstand nicht. Zum Zeitpunkt deiner Antwort waren jedoch die Randbedingungen seitens des OP noch nicht so klar formuliert, so dass dein Lösungsvorschlag mehr in Richtung allgemeine Vorgehensweise ging. Deswegen haben wir durch meine Antwort darauf nun einen allgemeinen Zweig und den konkreten. Ich hoffe, nun wird es etwas klarer.

Du:

Da er - wie nun bekannt ist - die Nachrichten selbst schreibt, würde ich einfach nur Datum mit sekundenfeiner Uhrzeit nehmen.

Das war der konkrete Fall.

Ich:

Der von Dir gezeigte Pragmatismus spricht dann aber auch dafür kurzerhand die ID zu nehmen - welche die Eingangreihenfolge ja (hoffentlich) abbildet.

In der Antwort bist du jedoch eher auf das Argument für die allgemeine Vorgehensweise eingegangen.

Du:

Das Problem ist das "hoffentlich". Niemand garantiert, dass das immer so ist. Nachher kommt noch jemand auf die Idee, Lücken zu füllen ...
Ich sehe eine Kreisdiskussion. Du setzt Prämissen an, die zwar für Deine eigene "Lösung" gelten sollen, aber nicht gelten sollen, wenn Du die andere Lösung als "falscher als die Deine" darstellst.

Immer noch die allgemeine Vorgehensweise.

Hier die von Dir nur für Dich gesetzte Prämisse:

Da er - wie nun bekannt ist - die Nachrichten selbst schreibt,

Konkreter Fall.

Und hier deren Aufhebung:

Niemand garantiert, dass das immer so ist. Nachher kommt noch jemand auf die Idee, Lücken zu füllen ...

Wieder das Allgemeine.

Wer sollte denn der "jemand" sein? Überleg mal!

Und das bezieht sich wohl wieder auf den OP-Fall. Wenn er die Zeit als Sortierkriterium nimmt, die ja mit Sekundengenauigkeit ausreichend fein ist, dann kann er seine IDs vergeben und Lücken füllen wie er mag. Das Problem des "hoffentlich aufsteigend" ist für ihn keins. Wenn er allerdings die IDs nähme ...

Die allgemeine Vorgehensweise ist ja kein Gesetz und so muss man sich in konkreten Fällen nicht strikt daran halten, weil andere Randbedingungen gelten. Hier haben wir, dass Dopplungen nicht auftreten werden und so muss er weder dafür Ausnahmen in irgendeiner pragmatischen Weise angehen, noch eine generell weniger optimale ID-Lösung nehmen.

Lo!

[Fred Furunkelstein]

Aha.

Deine Lösung ist also ganz toll, weil diese immerhin im von Dir eingeschränkten Rahmen funktioniert und die Lösungen der anderen sind ganz  schlecht, weil diese zwar in dem von Dir eingeschränkten Rahmen auch funktionieren - nur eben nicht unter anderen Prämissen, bei denen übrigens auch Deine Lösung "voll fürn Arsch"  ist.

Ich habe Dich absolut richtig verstanden.

Fred.

[dedlfix]

Hi!

Ich habe Dich absolut richtig verstanden.

Schade, denn dem und deiner (nicht mehr zitierten) Schlussfolgerung kann ich nämlich überhaupt nicht zustimmen.

Lo!

[ChrisB]

Hi,

Aha.

Deine Lösung ist also ganz toll, weil diese immerhin im von Dir eingeschränkten Rahmen funktioniert und die Lösungen der anderen sind ganz  schlecht, weil diese zwar in dem von Dir eingeschränkten Rahmen auch funktionieren - nur eben nicht unter anderen Prämissen, bei denen übrigens auch Deine Lösung "voll fürn Arsch"  ist.

Ich habe Dich absolut richtig verstanden.

Fred.

Man könnte fast den Eindruck gewinnen, fastix wäre doch (viel) früher zurück gekehrt, als angekündigt …

Aber egal, ob dem so ist oder nicht – das Forum scheint auf jeden Fall ein neues Furunkel am Allerwertesten zu haben.

MfG ChrisB

[Fred Furunkelstein]

das Forum scheint auf jeden Fall ein neues Furunkel am Allerwertesten zu haben.

Ich habe Deine Ausfälligkeit zur Kenntnis genommen.

Fred

[dedlfix]

Hi!

bei der Ausgabe meiner News würde ich gerne als Spielerei die letzte und die nächste Nachricht anzeigen lassen, sortiert nach dem Datum (date-Format).

Wie geht denn das logisch? Wenn es die letzte Nachricht ist, wie kann dann noch eine nächste folgen? Selbst wenn das "letzte" wie so oft üblich im Sinne von "neueste" verwendet wird, kann danach noch keine nächste stehen.

Für Tipps und konkrete Code-Schnipsel wäre ich sehr dankbar!

Wenn ich mal von einer Nachricht X annahme, du willst die vorhergehende und die nachfolgende anzeigen, dann brauchst du eine nach der Zeit sortierte Menge. Davon kannst du einfach von einem Element X ausgehend auf Vorgänger und Nachfolger zugreifen. Wie stellst du dir konkrete Codeschnipsel vor, wenn du noch nicht mal konkret geworden bist, wo du die Nachrichten speicherst?

Lo!

[Steel]

Moin!

Wie geht denn das logisch? Wenn es die letzte Nachricht ist, wie kann dann noch eine nächste folgen? Selbst wenn das "letzte" wie so oft üblich im Sinne von "neueste" verwendet wird, kann danach noch keine nächste stehen.

Genau das hab ich mich auch gefragt. Ich glaube es ist nicht die aktuellste Nachricht gemeint, sondern die gerade 'aktive'.

[Fritz]

In der Tat meine ich die "aktive" Nachricht. Dass hinter der letzten Nachricht keine weitere mehr kommt, ist klar :-).

Gibt es denn noch weitere Fragen die offen sind? Gespeichert sind die Daten in einer Mysql-Datenbank, abgefragt werden sollen sie mit Php. Das Format des Datums ist das date-Format.

[ChrisB]

Hi,

Gibt es denn noch weitere Fragen die offen sind?

Meinerseits erst mal nicht.

MfG ChrisB