Czy podział na strony zmniejsza obciążenie serwera? (teoria)

Zastanawiałem się, jaki jest powód paginacji? Czy jest używany, ponieważ zmniejsza obciążenie serwerów, ponieważ technicznie ograniczamy liczbę wierszy zwracanych na stronę?

Chciałem zrobić coś bez podziału na strony, ale biorąc pod uwagę, że jestem nowy (jestem amatorem), zacząłem się zastanawiać, czy technicznie jest OK.

Istnieje wiele powodów podziału na strony, zmniejszenie obciążenia serwera to tylko jeden z nich. Jednak Stephen Orr podnosi ważny punkt - nadal musisz najpierw znaleźć ilość danych. Musisz upewnić się, że to zapytanie jest szybkie i nie powoduje nadmiernego obciążenia serwera.

Inne powody to:

• Zmniejszenie ilości danych zwracanych do klienta za jednym razem. Jeśli masz dużo danych, może to zająć sporo czasu i zająć dużo pamięci.
• Użytkownik często nie jest zainteresowany wszystkimi danymi, ale tylko najnowszymi (powiedzmy). Zwracając tylko kilka stron danych, których nie otrzymujesz, użytkownik nigdy nie zobaczy.

W obu tych przypadkach nie chcesz, aby użytkownik czekał - na dane, których nie będą oglądać, lub na wszystkie dane, gdy mogą uzyskać jeden z przetwarzania niektórych z nich.

Różni się w zależności od implementacji.

Przyspieszy renderowanie strony, ale niekoniecznie zmniejszy obciążenie serwera. Większość naiwnych algorytmów stronicowania musi najpierw wykonać zapytanie, aby zdecydować, ile stron powinno być, a następnie ponownie wykonać zapytanie, aby uzyskać zestaw wyników „stronicowany”.

Największą korzyścią wynikającą z paginacji jest zwiększenie szybkości aplikacji przez:

1 - Ograniczanie danych przesyłanych między klientem a serwerem. Nie ma sensu czytać 1000000 klientów, jeśli użytkownik szuka 10 z nich.

2- Znacząco przyspieszenie wydajności zapytania poprzez pobieranie tylko wierszy pasujących do widoku użytkownika. Nie ma sensu czytać 1000000 klientów, jeśli użytkownik spojrzy na pierwszych 10 klientów.

3 - Podział na strony pomaga, dostarczając więcej świeżych danych. Jeśli aplikacja wyświetla wiele wierszy danych, a domena aplikacji wymaga dużej aktualizacji wierszy danych w wyświetlanej tabeli, istnieje prawdopodobieństwo, że do czasu przejścia na stronę 20 listy stron dane w niektórych wierszach byłyby zmienione. Pomyśl o aplikacji, która odczytuje ceny akcji lub dostępne pokoje w hotelu. Pobieranie starych danych i umieszczanie ich na kliencie jest bezużyteczne.

Podział na strony to jedna ze strategii, która w połączeniu z filtrowaniem i zrozumieniem potrzeb użytkownika końcowego w danym scenariuszu (który ma doprowadzić do dobrego projektu spełniającego tę potrzebę) znacznie poprawi aplikację, szczególnie gdy kilku użytkowników trafi do bazy danych jednocześnie.

Programowanie stronicowania nie zawsze jest banalne. W niektórych przypadkach jest to proste, ale czasami jest bardzo skomplikowane, aby zapytanie SQL było wykonywane bez wykonywania pełnego skanowania tabeli. Zależy to oczywiście od twoich indeksów, warunków filtrowania i twojego oświadczenia Where.

Moim zdaniem paginacja jest matką wszystkich przedwczesnych optymalizacji. Tworzenie strony bez podziału na strony jest całkowicie w porządku.

Jeśli po wydaniu okaże się, że ładujesz za dużo danych w jednym połączeniu lub że użytkownicy muszą czekać na informacje, których chcą, ponieważ jest zajęty ładowaniem danych, których nie chcą, śmiało napisz rozwiązanie Ajax który ładuje stronę tylko wtedy, gdy ludzie przewijają w dół (patrz: Twitter, Tumblr, wyszukiwanie grafiki Google).

Edycja: Drugi akapit powyżej został napisany przy założeniu, że powszechną odpowiedzią byłoby „ale jeśli wiesz, że w pewnym momencie zamierzasz dokonać paginacji, równie dobrze możesz to zrobić wcześniej, zamiast marnować czas na rozwijanie czegoś, co zamierzasz rzucić z dala."

Oprócz bycia matką wszystkich przedwczesnych optymalizacji, myślę, że paginacja jest koszmarem UX i że istnieją lepsze rozwiązania, które nie wymagałyby dodatkowego rozwoju na całej stronie.

Pomimo liczby głosów negatywnych, zostawiam tę odpowiedź tutaj, ponieważ podtrzymuję sentyment, nawet jeśli nie był to mój najlepszy tekst.