Sven Rautenberg: MySQL: Workaround für NEXT und PREVIOUS gesucht

Beitrag lesen

Yo, Tom!

für PREVIOUS:

Select Kunde, ID from kontakte where ID < 19 order by kunde,id Desc limit 1

für NEXT:

Select Kunde, ID from kontakte where ID > 19 order by kunde,id  limit 1

wobei die 19 für den aktuellen Datensatz steht. Das minimiert die zu haltenden Daten auf die ID und die Order, hier sortiert nach Kunde und Subset ID

Tja, die Frage ist nur, ob dir das wirklich weiterhilft. Ich denke, du kriegst auf diese Weise es zwar in den Griff, nacheinander die IDs durchzukaspern, aber nicht, so nacheinander die Namen durchzukaspern.

Zuerst ganz kritisch angucken würde ich die Reihenfolge der Sortierung. Denn es wird zuerst nach Namen sortiert, dann nach IDs. Du kannst also dadurch folgenden Fall erhalten (je nachdem, in welcher Reihenfolge die Namen eingetragen wurden!):

ID   Name
3    Meier
4    Meier
1    Müller
5    Müller
2    Walther

Sortiert nach Namen und dann nach IDs.

Angenommen, du bist jetzt bei der ID 4 - Dann wäre der nächste Datensatz die ID 1. Du selektierst aber nur die IDs, die größer als die 4 sind, also ID 5. Damit fällt der Müller/ID 1 aus deiner Liste heraus.

Ich verstehe nicht, wieso du nicht in der Lage bist, einfach einen Datensatzzeiger zu erfinden, der vollkommen unabhängig von irgendwelchen IDs ist, und einfach nur auf das derzeit angezeigte Ergebnis der sortierten Tabelle aus der Datenbank zeigt.

Dieser Datensatzzeiger ist genauso aufwendig, wie deine ID, nur kann man durch simple Addition oder Subtraktion von 1 den vorhergehenden oder nächsten Datensatz erhalten, ohne mit IDs, der Datenbanksortierung etc. ins Gehege zu kommen.

Du fragst also immer schön die Datenbank ab mit deinem Query, und die Einschränkung durch LIMIT kommt von außen herein, ohne auf Datenbankdaten zu beruhen.

Damit bist du dann verantwortlich, diesen Datensatzzeiger in der Session zu behalten, und nicht die Datenbank.

Im Prinzip ist an deinen Funktionen garnichts zu ändern - außer daß sie intern umgestrickt werden müßten, um nicht mehr auf ID-Basis zu arbeiten, sondern diesen Datensatzzeiger zu benutzen.

Diese zwei Werte wird man dann wohl im Form halten können, sodass sessionübergreifend gestept werden kann. Da hat ja CK so drauf rumgeritten, obwohl ich gar nicht verlangt hatte, dass irgendwo Zeiger oder ähnliches gehalten werden.

Bei ca. 1.500.000 Datensätzen kann man nur nicht jedesmal ein vollständiges Resultset anfordern, oder?

Wenn du "WHERE ID > 19" abfragst und 1,5 Mio Datensätze hast, dann werden 1,499981 Mio Datensätze in eine Tabelle gelegt, dann sortiert nach Name und ID, und dann gekürzt auf einen Eintrag. Anders ist ein korrektes Ergebnis doch garnicht hinzukriegen. Das wird nur performant, wenn du Indices in der Tabelle benutzt. Es vermeidet aber garnichts. Das könntest du nur, wenn dir exakt die nachfolgende ID bekannt wäre, die du mit "WHERE ID = 21" abfragen könntest. Dann würde das Sortieren und Limitieren mutmaßlich wegfallen können. Dazu müßtest du aber einmalig die gesamte sortierte Tabelle abfragen und die IDs zwischenspeichern, damit dir die ID-Reihenfolge bekannt ist. Ich würde meinen, daß das auch nicht besonders hilft.

- Sven Rautenberg