Это очень хороший вопрос, и нет единого хорошего ответа для каждого случая. Я использовал и видел различные стратегии, каждая из которых имеет свои плюсы и минусы.
Загрузка сразу - хорошо, это хорошо с небольшими таблицами и когда данные фильтруются. Когда пользователь переходит на другие страницы, никакие дополнительные запросы не отправляются в базу данных. Минус - высокая стоимость при начале взаимодействия и очень высокие требования к памяти. Когда типичен, пользователь не будет прокручивать все данные, это пустая трата ресурсов. Однако для небольших словарей это, вероятно, лучшее решение.
Пейджинг с использованием лимита / смещения (PostgreSQL), rownum (Oracle) или любого другого ключевого слова. Плюс - высокое время загрузки первой страницы. Минус - каждая следующая страница загружается медленнее, с более тяжелой работой на сайте базы данных. Лучшая стратегия, когда пользователь обычно видит одну или несколько первых страниц. Худшее, когда пользователь прокрутит все данные. Это работает довольно хорошо, когда набор упорядочен по первичному ключу, однако ужасно, когда набор данных фильтруется и упорядочивается не по индексу. Для каждой страницы она вызывает фильтрацию (возможно, с полным сканированием таблицы) и сортировку полного набора данных в памяти!
Прокрутка с использованием курсора базы данных. Это самая опасная стратегия. База данных открывает курсор для запроса, и когда пользователю требуется следующая страница, курсор перемещается. Оптимальная стратегия для случая, когда пользователь обычно просматривает все данные. Предпочтительная стратегия для отчетов. Однако в интерактивном режиме пользователя требуется, чтобы соединение с базой данных было заблокировано на время взаимодействия. Никто другой не может использовать это! А количество подключений к базе данных ограничено! Это также очень сложно реализовать в веб-приложении, где вы не знаете, закрыл ли пользователь браузер или все еще анализирует данные - вы не знаете, когда прервать соединение.