In diesem Artikel wird beschrieben, dass die Offset-Anweisung nicht der richtige Weg sei um Pagination umzusetzen. Das Problem sei, dass trotz Offset immer noch alle Datenbankeinträge geholt werden, selbst die später übersprungenen. Offset ist aber genau das Mittel, mit dem ich normalerweise Pagination umsetzen würde, beispielweise in ursprung – aber auch Serendipity macht das so.
Mit Offset ist das hier gemeint:
offset = totalEntries - (limit * page)
@@db.execute "SELECT id FROM entries WHERE deleted != 1 ORDER BY date DESC LIMIT ?,?;", offset, limit
Basierend auf der aktuellen Seitenzahl wird offset erhöht oder reduziert, sodass nur ab der aktuellen Seite Einträge geholt werden. Dann reduziert ein LIMIT die Liste.
Die Alternative:
SELECT ...
FROM ...
WHERE ...
AND id < ?last_seen_id
ORDER BY id DESC
LIMIT 10
Statt offset werden die Einträge ab dem letzten gesehenen Eintrag geholt, der Seitenmarkierung, z.B. dem ältesten Eintrag auf der vorherigen Seite.
Damit das in einem Blogsystem funktioniert, bei dem die Einträge nach Datum und nicht nach id sortiert sind, müssen die Pagination-Links also nicht mehr eine Seitenanzahl haben, sondern das Datum des vorherigen Eintrags. Ich sehe auch noch keinen Weg, echte Pagination zu bauen – also nicht nur zwei Links weiter und zurück, sondern einzelne Links für jede einzelne Seite; die einzelnen Links sind ja nicht bekannt. Auch braucht man leicht verschiedene SQL-Abfragen, um vor- und zurück zu gehen, und zusätzlichen Code, um festzustellen wann man auf der letzten der ersten Seite ist. Dinge wie ein stabiles Archiv sind auch schwieriger.
Eventuell ist all das lösbar, indem man beim Speichern eines neuen Eintrags die Navigation vorberechnet, sodass Seitennavigation auf Datumsgrenzen gemappt wird.
Dafür muss sich all das aber lohnen. Was für Auswirkungen hat es auf die Performance? Tatsächlich war in meinem Test die Pagination ohne Offset deutlich schneller. Für diesen Test habe ich ursprung modifiziert, zwei Testinstallationen (eine mit, eine ohne Offset) mit je 10000 Lorem-Ipsum-Einträgen befüllt und die Archivseite mit Eintrag 5000 aufgemacht. Dies ist die Server-Wartezeit:
60% schneller – und der Unterschied sollte bei mehr und mehr längeren Einträgen größer werden. Das ist ziemlich gut.
Die Frage ist, wieviel davon übrigbleibt wenn alle Probleme beseitigt werden, wie das Nicht-Anzeigen der Pagination-Links wenn es keine nächste Seite gibt. Aber angesichts des bisherigen Ergebnisses werde ich wohl versuchen, das zumindest für ursprung zu implementieren.
Für s9y dürfte es zu schwierig sein.
onli blogging am : No-Offset Pagination in ursprung
Vorschau anzeigen