Автор оригинала: Vlad Mihalcea.
Вступление
В этой статье мы обсудим несколько лучших и наихудших методов разбиения данных на страницы.
Разбиение данных на страницы вездесуще в корпоративных приложениях. Тем не менее, большинство решений не только предлагают плохой пользовательский интерфейс, но и неэффективны.
Лучшие практики разбиения на страницы @vlad_mihalcea https://t.co/0TMpEGTYeF pic.twitter.com/2KymI0DYfn
Проблема разбиения на страницы решает
Если в вашей базе данных было всего дюжина записей, вы можете просто извлечь все данные и отобразить их пользователю. Однако это почти никогда не бывает так. Чаще всего записи в таблицах базы данных варьируются от десятков строк до миллиардов записей.
Извлечение большого объема данных занимает значительное количество времени. Это связано с тем, что необходимо проделать большую работу по перемещению больших объемов данных с сервера базы данных в пользовательский интерфейс:
- данные должны быть отсканированы с диска и загружены в буферный пул сервера базы данных
- загруженные данные отправляются по сети
- сервер приложений получит данные в табличной форме (например, JDBC
Набор результатов). - приложение преобразует табличные данные в древовидные структуры (например, сущности, DTO).
- древовидная структура преобразуется в JSON и отправляется по сети в браузер
- браузеру необходимо загрузить весь JSON и использовать его для создания пользовательского интерфейса
Мало того, что извлечение больших объемов данных крайне неэффективно, но это также вредит пользовательскому опыту. Представьте, что вам нужно загрузить список из десятков тысяч записей на свой мобильный телефон по измеренному соединению. Загрузка этого конкретного большого списка будет медленной, дорогостоящей и невозможной для навигации на мобильном телефоне с очень ограниченным окном просмотра.
Таким образом, по всем этим причинам разбиение на страницы используется таким образом, чтобы одновременно извлекалось и отображалось только небольшое подмножество всего набора данных.
Классический макет разбиения на страницы
Теперь наиболее распространенный способ выборки результирующего набора-разделить его на несколько страниц или подмножеств данных. Один из таких примеров можно увидеть на старом форуме Hibernate :
Существует более 66 тысяч сообщений, которые разделены на 2600 страниц. Хотя вы практически можете перейти на любую из этих страниц, на самом деле это не очень полезно.
Почему я должен хотеть перейти на страницу номер 1758? Или как легко я мог бы найти интересующую меня тему, тысячу раз перескакивая с одной страницы на другую?
Ограничение на количество страниц
При поиске менее избирательного термина в Google вы можете получить очень большой список возможных страниц, соответствующих поисковым ключевым словам.
Итак, при поиске “Гибернации” Google сообщает, что у него 22 миллиона результатов. Однако Google предоставляет только наиболее релевантные 16 или 17 страниц:
Дело в том, что немногие пользователи когда-либо переходят на вторую или третью страницы. Большинству пользователей даже не нужно переходить с одной страницы на другую, потому что есть гораздо лучший способ найти именно то, что вас интересует. Вам просто нужны более избирательные поисковые запросы.
Таким образом, уточняя условия поиска, мы получаем гораздо больше шансов найти то, что нас интересовало:
Лучшие способы фильтрации
Разбиение на страницы-это хорошо, особенно потому, что оно позволяет извлекать только небольшое подмножество данных за один раз. Однако навигация по страницам полезна только в том случае, если количество страниц невелико. Если у вас десятки или сотни страниц, то пользователям будет очень трудно найти то, что их интересует.
Вместо этого пользователю нужен лучший инструмент фильтрации. Вместо того, чтобы вручную сканировать каждую страницу, было бы намного лучше, если бы приложение могло делать это автоматически, если вы предоставляете высокоселективные условия поиска.
Для разработчиков приложений это означает, что они должны предоставить способ уточнения набора результатов, либо путем предоставления дополнительных критериев фильтрации, либо с помощью более подробного описания поискового запроса.
Таким образом, приложение может получить точное подмножество данных, которые интересуют пользователя, и пользователь быстро найдет нужную запись из суженного набора результатов.
Вывод
Хотя разбиение данных на страницы является очень распространенным требованием, многие реализации рассматривают проблему только с математической точки зрения, а не решают ее с точки зрения пользователя.
Таким образом, ограничение количества страниц на самом деле очень полезный трюк, поскольку он позволяет пользователю сосредоточиться на предоставлении правильных условий поиска. С точки зрения базы данных ограничение количества страниц является мерой безопасности, так как один запрос, извлекающий миллиарды записей, может в конечном итоге потреблять все ресурсы базы данных (процессор, память, пропускную способность ввода-вывода), что влияет на доступность приложений.