Stronicowanie wyników publikowanych na stronie internetowej można zrealizować na wiele sposobów. Niestety — żaden z nich nie jest idealny. Mówiąc o paginacji, mam na myśli proces pobierania danych z tabeli w bazie danych i przekazywania ich do frontendu, aby wyświetlić je jako tabelę podzieloną na strony. W większości aplikacji użytkownik może wybrać, ile wierszy ma zawierać jedna strona, przechodzić między stronami przyciskami „następna” i „poprzednia”, albo wpisać dowolny numer strony mieszczący się w zakresie dostępnych danych.
Kiedy stronicowanie ma sens?
Odpowiadając na to pytanie, zastanówmy się najpierw, z jakimi wielkościami zbiorów danych możemy mieć do czynienia (chodzi o liczbę rekordów zwracanych z bazy):
- Kilka rekordów (0–30)
- Załóżmy, że wyświetlamy tabelę z listą parametrów jakiegoś systemu lub produktu. W takich przypadkach liczba rekordów zwykle nie przekracza kilku lub kilkunastu pozycji. Stronicowanie nic nam tutaj nie daje — całość zawsze mieści się na jednej stronie.
- Kilkaset rekordów (30–1000)
- Mając mniej niż 1000 rekordów, nadal możemy bez problemu wyświetlić wszystko na jednej stronie. Kiedyś przeglądarki gorzej radziły sobie z renderowaniem dużej liczby elementów, ale dziś nawet wyświetlenie 1000 wierszy nie stanowi większego wyzwania.
- Bardzo duże zbiory danych (miliony)
- Jeśli mamy do czynienia z milionami rekordów, klasyczne stronicowanie i tak nie ma sensu. Użytkownik musiałby godzinami klikać kolejne strony, żeby przejrzeć całość, a i tak najczęściej będzie chciał wyszukać lub odfiltrować interesujące go dane. W tak ogromnych zbiorach paginacja nie rozwiązuje prawdziwego problemu: skutecznego wyszukiwania i filtrowania.
- Zbiory dynamiczne (ciągle zmieniające się dane)
- Niektóre dane zmieniają się tak szybko, że tradycyjna paginacja w ogóle nie działa. Logi, zdarzenia systemowe, statusy zamówień czy dane telemetryczne — w takich przypadkach wpisy są dodawane i modyfikowane cały czas. Po kilku sekundach strona nr 2 może wyglądać zupełnie inaczej niż przed chwilą. Skutek? Użytkownik widzi duplikaty, brakujące rekordy albo przeskakujące wyniki.
Analizując powyższe przypadki, łatwo zauważyć, że w skrajnych scenariuszach stronicowanie w ogóle nie ma sensu. Gdy rekordów jest bardzo mało — paginacja nie jest potrzebna z oczywistych względów. Gdy rekordów są miliony — użytkownik i tak nie przejrzy wszystkich stron, więc paginowanie ogromnych zbiorów mija się z celem. W praktyce jedynym przypadkiem, który w ogóle uzasadnia stosowanie klasycznej paginacji, są średniej wielkości zbiory: wystarczająco duże, aby nie zmieściły się na jednej stronie, ale jednocześnie na tyle małe, by użytkownik faktycznie był w stanie przejrzeć wszystkie strony.
Inna kwestia jest taka, że projektując stronicowanie, bardzo często w ogóle nie wiemy, z jakiego rzędu wielkości dany zbiór danych będzie w przyszłości. Zwykle musimy więc przyjąć scenariusz pesymistyczny — czyli założyć, że rekordów może być nawet milion lub więcej. A skoro musimy przygotować się na tak duże wolumeny, to i tak dochodzimy do tego samego wniosku: klasyczne stronicowanie przestaje mieć sens.
Dlaczego stronicowanie jest problematyczne?
Stronicowanie ma wiele wad, z których większość opisałem już w innym artykule o paginacji: https://devreview.pl/nie-dla-sql-offset/. Do tej listy warto dodać jeszcze jeden istotny problem: aby paginacja miała sens, w większości przypadków należałoby poinformować użytkownika, ile stron musi przejrzeć, aby dotrzeć do końca zbioru danych. Żeby to zrobić, backend musi za każdym razem wykonać dodatkowe zapytanie COUNT(*), aby poznać całkowitą liczbę rekordów i policzyć liczbę stron.
To oznacza dodatkowe koszty wydajnościowe oraz kolejne obciążenie bazy danych.
W przypadku proponowanego podejścia taki count nie jest w ogóle potrzebny — i to jest jedna z jego największych zalet.
Jak przeglądać dane bez stronicowania?
Chciałbym przedstawić Ci nieco kontrowersyjną metodę pracy z dużymi zbiorami danych — podejście, w którym… po prostu nie tworzymy paginacji w ogóle.
Tak, dokładnie tak.
Jak opisałem wcześniej, klasyczne stronicowanie ma sporo wad: wymusza wybór konkretnej metody paginacji, narzuca kompromisy, generuje dodatkowe obciążenia wydajnościowe, a na końcu i tak okazuje się niewystarczające.
Dlaczego niewystarczające?
Bo jeśli zbiór danych jest zbyt duży, aby użytkownik mógł go przejrzeć strona po stronie, to i tak musimy dodać kryteria wyszukiwania. Użytkownik musi mieć możliwość zawężenia listy tak, aby interesujące go wyniki znalazły się od razu na pierwszym ekranie.
Przykład: lista pracowników.
Niezależnie od liczby rekordów i sposobu paginacji, i tak prędzej czy później dodamy filtry typu: imię, nazwisko, adres, dział, stanowisko itd.
Mając te filtry, użytkownik zawsze jest w stanie znaleźć to, czego potrzebuje — a my możemy po prostu wyświetlić pierwsze 100 wyników, informując jednocześnie, że jeśli nie widzi wśród nich tego, czego szuka, to powinien bardziej zawęzić kryteria wyszukiwania.
Podsumowanie
Klasyczne stronicowanie przez lata wydawało się oczywistym rozwiązaniem – tak oczywistym, że niewielu programistów w ogóle podważało jego sens. Dopiero kiedy przyjrzymy się bliżej różnym skalom danych, kosztom wykonywania dodatkowych zapytań COUNT(*), kompromisom wydajnościowym i faktycznym potrzebom użytkowników, staje się jasne, że paginacja nie jest ani neutralnym, ani dobrym wyborem.
W skrajnych przypadkach (bardzo małe lub bardzo duże zbiory) paginacja nie wnosi absolutnie nic. W przypadkach pośrednich działa tylko „jako tako”, a i tak finalnie wymaga dodania filtrów i mechanizmów wyszukiwania, które rozwiązują prawdziwy problem—pomagają użytkownikowi znaleźć to, czego szuka.
Dlatego podejście oparte na filtrowaniu i prezentowaniu jedynie ograniczonej liczby najbardziej trafnych wyników bywa nie tylko prostsze, ale przede wszystkim bardziej użyteczne. Użytkownik nie musi klikać w dziesiątki stron. Nadal dostaje to, czego potrzebuje. A my eliminujemy zbędne komplikacje, koszty wydajnościowe i niepotrzebną architekturę.
Paradoksalnie więc najlepszym sposobem na „paginację” często jest… kompletne zrezygnowanie z paginacji.
To rozwiązanie prostsze, szybsze i — co najważniejsze — naprawdę przyjazne użytkownikowi.
Warto też spojrzeć na paginację z zupełnie innej perspektywy: stronicowanie nie powstało z myślą o użytkownikach. To rozwiązanie techniczne, stworzone przez programistów, aby chronić backend przed zalaniem go zbyt dużymi zapytaniami. Użytkownik wcale nie chce klikać po stronach. Nie interesuje go, czy rekord, którego szuka, znajduje się na stronie 1, 7 czy 42. On chce natychmiast znaleźć konkretną informację.
W tym ujęciu paginacja okazuje się nie tyle funkcjonalnością, co obejściem problemu braku lepszych narzędzi. Prawdziwym rozwiązaniem są mechanizmy, które pozwalają dotrzeć do danych szybko i precyzyjnie: wyszukiwanie, filtrowanie oraz sortowanie.
To one realizują faktyczne potrzeby użytkownika. Paginacja tylko maskuje ograniczenia systemu.
Medium
You can read the English version on Medium: https://medium.com/@gentoo2x/pagination-is-a-scam-the-user-does-not-need-it-anyway-c42283386624
