Номера страниц в постраничной выборке — зачем?

Question

[vajadhava]

Не люблю индексы страниц в постраничной выборке.

Т.е. классические эти самые цифорки 1,2,3,4,5 в этом вот:

<a href="#">&lt;&lt;</a> <a href="#">&lt;</a> <a href="#">1</a> <a href="#">2</a> <a href="#">3</a> <a href="#">4</a> <a href="#">5</a> <a href="#">&gt;</a> <a href="#">&gt;&gt;</a>

Навигатор предыдущая-следующая люблю. Переход на первую — люблю. А их, номерочки страниц эти вот — нет.

Для чего они нужны тоже не понимаю (разве что косвенно посмотреть: ого себе, понавыбирал страниц).


Например у меня есть некая таблица, со списком городов мира:

| Название | население | дата основания | ... |


Допустим, есть индексы страниц. Очевидно что страниц over 9000. Как должен выглядеть такой индекс, чтобы мне удобно было им пользоваться?

Видится мне что over 9000 номеров страниц, разделенных пробелами займут экранов 10, не меньше, но зато я смогу перейти на нужную страницу одним кликом. Но так никто в здравом уме наверное уже не делает (исключая, конечно, суперпопулярный в моем городе forums.kuban.ru, хотя и они уже на диапазон перешли).

Вариант с номерами страниц в html select-е сразу отбрасываю (поместятся все индексы, много места не съедят, но пользоваться селектом с over 9000 мягко говоря неудобно).

Вариант гуглояндексов, когда отображаются не все индексы, а лишь из некоего диапазона, т.е.

<a href="#">&lt;&lt;</a> <a href="#">&lt;</a> <a href="#">90</a> <a href="#">91</a> <a href="#">92</a> <a href="#">93</a> <a href="#">94</a> <a href="#">95</a> <a href="#">96</a> <a href="#">97</a> <a href="#">98</a> <a href="#">99</a> <a href="#">100</a> <a href="#">&gt;</a> <a href="#">&gt;&gt;</a>

(все просто, я кликаю в 100-ю страницу, и прокручиваю индекс в диапазон 100 — 110). Но при таком раскладе чтобы перейти на 678 страницу мне нужно кликнуть 66 раз. Блин, печально.


Ладно, наверное нужно понять зачем мне вообще понадобилось переходить на какую-то конкретную страницу. Например на 7-ю. Или на 25-ю. Или на 177-ю.

Пока я вижу два варианта:


1. Из любопытства (действительно, а что же там на 177-й странице? Может Воронеж?). Эдакий серфинг по контенту. Бред.

2. Я знаю что-то о содержимом 177 страницы (в прошлый раз там был Воронеж все же).


Раз я знаю что-то о содержимом, значит я могу использовать поиск или фильтр, и сократить количество страниц с over 9000 возможно до 1 или 2 или 3.? Маловероятно что индексы страниц в постраничке мне помогут (внесли еще городов и Воронеж уполз на 179 страницу, блин… или на 177 был Волгоград, а Воронеж на 166?… или это была Вологда, а Воронеж был на 154?.. так, запоминаем индексы, запоминаем, голова наполняется нужными и полезными знаниями...). Вобщем в любом случае мне без фильтра не обойтись, так нафиг все эти котлеты с номерами, если толку от них меньше чем от мух.


Посмотрим на это все со стороны сервера (и СУБД).

Для построения индексов страниц в постраничке мне нужно знать количество записей. Причем без учета START, LIMIT ограничений, передаваемых в запрос для ограничения вывода на страницу. Так, ну хорошо, будем использовать select count(1) from ... where <фильтры> .... Таблица весит 10 Гб, о, ура, есть индекс какого-то внешнего ключа всего на гиг, будем сканировать его.

Или дополнительно сканировать гиг просто для того чтобы нарисовать номерки страниц — не ура (подумала СУБД)? И при любом изменении фильтра сканировать заново (а без фильтра как я уже понял мне в любом случае не светит найти мой любимый Воронеж)? Или даже при переходе на следующую страницу? (О-о, подумала СУБД).


Наверное можно как-то кэшировать счетчик (для каждого набора фильтров). Наверное можно при переходе на следующий индекс в get-запрос запихивать параметром и это значение (число строк, выбранных на первой). В любом случае связанном с кэширование есть вероятность упустить свежие данные, для таблиц, из которых не только читают. Наверное можно как-то еще изголяться, в попытках понизить нагрузку на сервер. Но: ради чего?


Итого, мой вариант:

<a href="#">первая</a> <a href="#">&lt;предыдущая</a> <a href="#">следующая&gt;</a>

и фильтры.

При выборке просто запрашиваем на одну запись больше чем нужно отобразить на странице. Если вернулись все записи, значит есть следующая страница (рисуем ссылку следующая>). Если переданный при переходе START не ноль, значит есть предыдущая (и первая). И не нужно отдельно вычислять количество строчек всякий раз когда отображаются данные, не нужно сканировать гигобайтный индекс (Ага, успокоилась СУБД).

Однако мегатонны вконтактов — однокласников — фэйсбуков — гуглояндексов с индексами в постраничке как бы намекают...

Answer 1

[sadyjka]

Подход с номерами страниц — общепринятый и вполне себе нормальный вариант.

На счет индекса в 10ГБ и его «скана» — для поиска по таким большим объемам информации, частенько используют внешние системы (Apache Solr, Sphinx и т.п.). Потому База не будет напрягаться.

Зачем Вам 177я страница? Это уже маразм какой-то… «А вдруг мне она понадобится, а вдруг я знаю, что на ней будет что-то ценное»…

Ваш вариант имеет право на жизнь, но опять же, пагинация очень зависит от специфики сайта, его контента и направленности.

«Однако мегатонны вконтактов — однокласников — фэйсбуков — гуглояндексов с индексами в постраничке как бы намекают..» — думаю что они достаточно хорошо знают, что делают :)

Удачи.

Comments

[vajadhava]

Спасибо.
Про общепринятый подход вполне понимаю и не спорю, люди привыкли. Хочу понять практически помогают кому-то эти индексы или нет. Из моей практики — скорее нет.
177 страница мне не нужна, но иногда я вынужден ей пользоваться. Например на ру-борде, где-нить в форумах, потому что я помню что где-то примерно там описан интересующий меня момент. Других инструментов для ограничения выборки данных там просто нет, как и на 100500 других форумах. И, блин, меня это очень расстраивает. Делать очередные, да, общепринятые инструменты, к которым все привыкли, но пользоваться которыми ад — не хочется :)

Answer 2

[freeznah]

>Ладно, наверное нужно понять зачем мне вообще понадобилось переходить на какую-то конкретную страницу
вам-не нужно, а я, к примеру, помню что нужная мне ссылка была «где-то между 203й и 207й страницей обсуждения Win7 vs Ubintu»
владельцам подобных индексаторов стОило бы еще и таймстампы прикрутить на номера страниц, для простоты ориентирования

Answer 3

[Vampiro]

imho постраничная навигация — атавизм, пришедший от бумажных изданий и оглавления. Основано во многом на инертности мышления, и совершенно не подходит для модифицируемого контента. Но любой иной подход будет связан с необходимостью перестраивать сознание и будет воспринят в штыки. Обратите внимание, что сейчас в ридерах используется полоса прокрутки, которая не показывает фактический номер страницы, а только визуально определяет «ближе к центру», или «где-то в начале».

Я морально на стороне автора поста, но понимаю на сколько тяжко будет это внедрять повсеместно. =((

Comments

[vajadhava]

Спасибо.
Да, толстым дядькам доказать что не нужно — ад. Аргументы «ну как не нужно, у всех же есть» =(

Answer 4

[konsoletyper]

А у меня на работе есть самописная система (не веб), где вообще нет разбиения и навигации. Грузим просто первые 1000 записей, которые подходят под условия фильтра, а дальше рисуем в последней строке таблички что-то, напоминающее оборванный лист бумаги. И правда, ну вот есть у нас той же номенклатуры 150 тыс. позиций. Зачем пользователю просматривать все 150 тыс. глазами? Он такое не переварит. Скорее всего, ему либо известен шрихкод (приехал в накладной от поставщика), либо примерное название, либо хотя бы товарная группа. Вначале пользователи плевались, мол «в адинэске я мог посмотреть все товары, а тут у вас какой-то поиск», но потом привыкли. Я думаю, что навигация из 100500 страниц — это всё от незнания пользователем, чего он хочет. А это, может быть, от неумения разработчиков донести до пользователей, для чего предназначена система.

Comments

[vajadhava]

Мне кажется что многовато 1000 записей для просмотра глазами. В дэсктопе максимум полтора-два скрина, а дальше нормальный грид сам умеет подтянуть следующую порцию, по скролу, хоть из всего набора, хоть перезапросить у БД. Хотя в дэсктопе дела с фильтрами-сортировками и т.д. намного проще, можно к примеру всю тысячу загрузить а потом уже с ней всякие вещи вытворять. Хотя глобально — факт что больше 1000 записей не нужно на пользователя тянуть (за редким исключением).

[konsoletyper]

Ну 1000 — это больше про запас. В реальности редко кто больше первых 20 рассматривает. А грузить надо ровно столько записей, сколько надо, потому что база-то общая. И сервер приложений тоже не резиновый.

Answer 5

[Николай Васильчук]

Если вернулись все записи, значит есть следующая страница (рисуем ссылку следующая>)

Вы не правы. 100 записей отлично делятся на 10 страниц по 10 записей, в вашем случае на десятой странице будет ссылка «следующая», а не должна.

Comments

[Николай Васильчук]

Простите, не прав я. Как-то проглядел строку

просто запрашиваем на одну запись больше чем нужно отобразить на странице

[vajadhava]

В общем-то я имел в виду выбирать 11 записей для страницы (но выводить по 10). Если есть 11-я значит есть следующая страница.

Answer 6

[rasa]

Наверно, надо посмотреть кто где и как развивал идею content pager'ов.
В Гугле я хожу по страницам с 5 по 15, посмотреть на какой странице мой сайт :)
На Руборде, например принято жать «версия для печати» (открывает содержимое ВСЕЙ ветки на одной странице) и далее поиском по странице найти нужный кусок. Очень часто перемещение по страницам делаю через указание оной в адресной строке (жесть по сути).
Вашу идею с первая предыдущая следующая можно улучшать и дальше — например сделать один контрол, где по hover «предлагать» переход как на первую, как на предыдущую, так и на следующую или фильтр.

Answer 7

[Stdit]

У каждого типа постранички своя специфика. Помимо собственно просмотра, постраничная навигация иногда нужна, чтобы пользователи могли давать друг другу ссылки на конкретные страницы. При этом, более логичным представляется использование в качестве точки отсчета не номер страницы умноженный на количество записей, а уникальный идентификатор сущности, по которому отсортированы записи и по которому составлен индекс в БД. Ссылки на такие страницы не ломаются, если в начале списка (на первой странице) появились новые записи. В другом случае, в статических списках (например в словарях или книгах), будет удобна классическая постраничная навигация + закладки на разделы или главы.

Answer 8

[rPman]

Пожалуйста, умоляю, не делайте постраничную выборку… всеми силами избавляйте пользователя от постраничного сканирования… это сложно/медленно для сервера (недавно анализировал очередной высер для распила госбюджета — выборка записи из справочника из 13т. записей 1500 страниц… кому такой бред нужен, кстати тормозит по 3 секунды на любой пшик)

Любой выбор больше 10-20 записей должен быть исключен (на самом деле можно потерпеть и 100… но больше значит где то забыли сделать возможность указания критерия выбора), там где это возможно — введением категорий, и в любом случае сделать полнотекстовый поиск-фильтр для данных с максимальной информативностью о результатах.

Выбор адреса — вообще классика, как только разработчики не изгаляются (сам помню извращался со сложной активной формой меняющей фильтр в полях выбора и их отображение). Пусть выводится полная строка из базы КЛАДР (страна, область, район, город/село, улица), а поиск полнотекстовый сразу по всем полям.

Comments

[rPman]

ошибся, 13т -> 31т.

[vajadhava]

Спасибо.

Answer 9

[Eternalko]

Лучший поиск что я видел реализован в программе search everything.