Каким образом можно реализовать пагинацию больших таблиц (свыше 100к записей) без потери производительности?
Запрос типа LIMIT 50000, 100 уже начинает подтормаживать. В интернете нашел решение, когда вместо номера страницы передается ID следующей записи и тогда запрос выглядит примерно так:
SELECT * FROM tale WHERE table_id>n LIMIT 100
Работает, кстати, очень хорошо! Но есть проблема: как отображать номера страниц? ID, понятное дело, PK AI. И всё бы отлично, но в нем существуют "дыры" от удаленных записей. Вот если бы их не было, посчитать номера страниц не представляло бы никакой сложности, путем элементарных арифметических действий.
Предлагаемые способы решения проблемы нашел такие:
1. "бесконечная страница" - а-ля фейсбук или контакт. Когда по мере прокрутки подгружается контент вниз страницы.
2. Не отображать номера страниц вообще, а сделать только кнопки: влево, вправо, первая, последняя. Технически самый простой и грамотный способ. Но вызывает большой вопрос в юзабилити.
3. Сообщить пользователю, что найдено 1389 страниц, но показывать не более 40-ка.
Проблема! Поисковики. То есть фактически для поисковых машин подходит только второй способ. Собственно говоря нет задачи отображать клиенту 100500 страниц. Все-равно ни один человек в здравом уме не пойдет дальше 20-30 страниц, даже самый
Короче, как по-человечески сделать? =))) Предлагаю открыть дискуссию, тем более были неоднократные призывы. ;)
Но обычно, когда есть кнопки "вперед", "назад", "на самую первую", "на самую последнюю", то там же делается и переход на определенную страницу. При указанном подходе можно только примерно перейти на произвольную страницу, "плюс-минус лапоть".