Ich hangle mich, stark vereinfacht wie folgt, seitenweise durch eine Tabelle mit Artikeln wobei je Seite 10 ($artikel_je_seite) Artikel angezeigt werden. In $start steht dabei quasi die Seitenzahl.

Nun wird z.B auf der dritten Seite der Artikel xy gezeigt, da er lt. "order by" ganz einfach an 23ter Stelle kommt.

Soweit so gut. Nun aber mal umgekehrt. Wenn ich nun als Ausgangsbasis den Artikel xy habe, wie kann ich dann darauf schließen auf welcher Seite er erscheinen wird, also an welcher Stelle er im select steht? Ich könnte natürlich einfach ein select über die ganze Tabelle machen und dann in einem Schleifenzähler alle gefundenen Datensätze durchlaufen bis der gesuchte Artikel gefunden wurde. Aber es müsste doch auch einfacher gehen, oder?

Kannst du eine partielle Ordnung über das irgendwas (aus der ORDER_BY-Klausel) erstellen?
Also kannst du die in eine Relation miteinander bringen, in der du die miteinnder vergleiche kannst?

Sowas wäre z.B. eine fortlaufende Artikelnummer. Wenn du die Artikel nach Artikelnummer aufsteigend sortierst, kannst du zählen, wieviele Artikel es bis zu einem egegebenen Punkt gibt, und daraus den Rückschluss ziehen, wieviele Seiten es gibt (wobei du da eventuell mit der *partiellen* Ordnung schon Probleme hast).

Ansonsten hangel ich mich gerade hier durch, eventuell ist da was für dich dabei.

Grüße, pktm

Wird wohl nicht gehen, da das Sortierkriterium variabel sein sollte. Also mal nach Preis, mal nach ArtNr, mal nach Text oder was auch immer ...

Das Ordnen sollte nicht das Problem sein, da Du für die ursprüngliche Abfrage ja auch geordnet hast. Das kannst Du dann bei der "Positionsbestimmung" genauso machen. Du brauchst nur noch eine Möglichkeit, den Eintrag, dessen Listenposition Du haben willst, eindeutig zu identifizieren.

Wenn Du die Liste mit
[sql]SELECT * FROM artikel ORDER BY irgendwas LIMIT $start , $artikel_je_seite[/sql]
erstellst, kannst Du mit
[sql]SELECT count(*) FROM artikel WHERE irgendwas < $ref_irgendwas[/sql]
zählen, wieviele Einträge vor dem gewünschten kommen, nachdem Du den Wert von irgendwas für den gesuchten Artikel herausgefunden und in $ref_irgendwas gespeichert hast.

Ja, aber wer sagt denn, dass $ref_irgendwas und irgendwas eine Zahl ist, die in einer Reihenfolge steht. Wenn du z.B. nach Artikelname sortierst, hast du Buchstaben, und auf denen ist die Ordnung < eben nciht mehr definiert.

@pktm: Hmm, ich dachte, alles was in ORDER BY stehen kann, hat auch einen definierten < Operator, oder zumindest einen definierten <= Operator. Aber vielleicht ist das auch nur bei PostgreSQL und SQLite so, was die Datenbanken sind, die ich am meisten verwende, oder es hat bisher einfach nur für alle Datentypen, mit denen ich es ausprobiert habe, funktioniert...

Nachtrag: Ich habe in der Dokumentation verschiedener Datenbanksysteme nachgelesen:

- Bei SQLite3 kann man wirklich alles miteinander per < oder <= vergleichen, im Zweifelsfall wird binär per memcmp verglichen, aber auf jeden Fall ist der Vergleich immer konsistent mit einer ORDER BY-Klausel. Man kann insbesondere nicht nur hinter ORDER BY sondern auch hinter jeden Ausdruck mit Vergleichsoperator eine COLLATE-Klausel setzen, um die Vergleichsfunktion explizit festzulegen.

- PostgreSQL kann mit ORDER BY alle Datentypen sortieren, für die eine B-Tree-Operatorklasse definiert ist. Man kann also einen benutzerdefinierten Datentyp erzeugen, auf dem < oder <= nicht oder inkonsistent mit der B-Tree-Operatorklasse definiert sind. Für alle eingebauten Datentypen gilt aber, dass sie sich entweder mit ORDER BY und < oder <= konsistent vergleichen lassen, oder gar nicht.

- Bei MySQL habe ich leider in der Dokumentation und mittels Google keine Informationen darüber gefunden, wie die Vergleiche genau funktionieren. Ein kurzes Experiment legt aber nahe, dass bei Stringvergleichen ähnlich wie bei SQLite3 auch hier eine Sortierreihenfolge angegeben werden kann und alle Datentypen, die man mit ORDER BY sortieren kann auch mit den Vegleichsoperatoren konsistent verglichen werden können.

Ich wage daher zu behaupten, dass man mit meinem Ansatz keine Probleme bekommen sollte, solange man immer gleiche Datentypen miteinander vergleicht. Wenn Konversionen zum Tragen kommen, was hier nicht der Fall sein dürfte, verhalten sich die verschiedenen Datenbanken wieder etwas weniger einheitlich.

Hm, das wäre interessant mal zu testen, aber ich habe gerade keine Zeit dafür ;-(

Hallo und danke erst mal für die Antworten.

Also eine Abfrage etwa in der Art scheint in dieser Tabelle unter MySQL tatsächlich das gewünschte Ergebnis zu produzieren, nämlich und es funktioniert sogar sowas mit diesem Ergebnis