Не люблю индексы страниц в постраничной выборке.
Т.е. классические эти самые цифорки 1,2,3,4,5 в этом вот:
<a href="#"><<</a> <a href="#"><</a> <a href="#">1</a> <a href="#">2</a> <a href="#">3</a> <a href="#">4</a> <a href="#">5</a> <a href="#">></a> <a href="#">>></a>
Навигатор предыдущая-следующая люблю. Переход на первую — люблю. А их, номерочки страниц эти вот — нет.
Для чего они нужны тоже не понимаю (разве что косвенно посмотреть: ого себе, понавыбирал страниц).
Например у меня есть некая таблица, со списком городов мира:
| Название | население | дата основания | ... |
Допустим, есть индексы страниц. Очевидно что страниц over 9000. Как должен выглядеть такой индекс, чтобы мне удобно было им пользоваться?
Видится мне что over 9000 номеров страниц, разделенных пробелами займут экранов 10, не меньше, но зато я смогу перейти на нужную страницу одним кликом. Но так никто в здравом уме наверное уже не делает (исключая, конечно, суперпопулярный в моем городе forums.kuban.ru, хотя и они уже на диапазон перешли).
Вариант с номерами страниц в html select-е сразу отбрасываю (поместятся все индексы, много места не съедят, но пользоваться селектом с over 9000 мягко говоря неудобно).
Вариант гуглояндексов, когда отображаются не все индексы, а лишь из некоего диапазона, т.е.
<a href="#"><<</a> <a href="#"><</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="#">></a> <a href="#">>></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="#"><предыдущая</a> <a href="#">следующая></a>
и фильтры.
При выборке просто запрашиваем на одну запись больше чем нужно отобразить на странице. Если вернулись все записи, значит есть следующая страница (рисуем ссылку следующая>). Если переданный при переходе START не ноль, значит есть предыдущая (и первая). И не нужно отдельно вычислять количество строчек всякий раз когда отображаются данные, не нужно сканировать гигобайтный индекс (Ага, успокоилась СУБД).
Однако мегатонны вконтактов — однокласников — фэйсбуков — гуглояндексов с индексами в постраничке как бы намекают... 
Простой
Простой
Средний
