Какие параметры у таблицы, по которой делается пейджинг? Интересует: - объем данных до фильтрации. - какие типичные объемы данных с фильтром, который пользователь вбивает в первую очередь? Какой разброс? Можно ли заставить сразу выбрать какую-то фильтрацию, или же нужно что-то показать сразу? - какой характер данных, нужно ли будет пользователю реально листать страницы на практике? - сколько параметров у фильтра (читай: "удастся ли эффективно реализовать все варианты фильтра")?
Как правило я принимаю одно из двух решений - или тупо TOP и полностью все на сервере, или тупо выгрузить сразу всё. Вариант "выгрузить все" довольно просто можно урезать до "выгрузить все что нужно для сортировки и фильтрации", а все остальное - догружать при необходимости.
Как частный случай последнего способа, можно выгружать только ID, да. Но это фиговое решение - и интерактивности не получишь, и сэкономишь только в случае если юзер тыкает пейджер (редко), а не в сортировку/фильтр (чаще). Причем на сортировке и фильтрации ты еще и потреяешь, т.к. базе надо сканить больше данных. Универсальность такого решения тоже под вопросом: у него все равно есть предел по количеству входных данных, пусть и в несколько раз побольше.
Я делал универсальное решение - переключать режимы грида на лету. Источник возвращает столько данных, сколько считает разумным. Также опционально считает count. А если хочет - возвращает все. Если вернули все - переключаемся в клиентский режим, где можем сортировать и дофильтровывать (т.е. сужать фильтр) без участия сервера. Типа набрали "сер" - сходили на сервер, он отдал все подходящие 60 строк, скинули на клиент, и дальше можем дофильровать до "сервера" или "сервисы" автономно.
Если вернули больше страницы - можем листать страницы на клиенте в этих рамках. Сортировать не можем. Дофильтровывать можем если получается больше страницы данных.
Также, если нам не вернули count, то мы заменяем пейджер с 1,2,3..6,7 на 1,2,3..6,show more. Ну и еще куча всяких тонкостей.
Так все вообще прикольно пашет, но я не видел таких готовых решений.
no subject
- объем данных до фильтрации.
- какие типичные объемы данных с фильтром, который пользователь вбивает в первую очередь? Какой разброс? Можно ли заставить сразу выбрать какую-то фильтрацию, или же нужно что-то показать сразу?
- какой характер данных, нужно ли будет пользователю реально листать страницы на практике?
- сколько параметров у фильтра (читай: "удастся ли эффективно реализовать все варианты фильтра")?
Как правило я принимаю одно из двух решений - или тупо TOP и полностью все на сервере, или тупо выгрузить сразу всё. Вариант "выгрузить все" довольно просто можно урезать до "выгрузить все что нужно для сортировки и фильтрации", а все остальное - догружать при необходимости.
Как частный случай последнего способа, можно выгружать только ID, да. Но это фиговое решение - и интерактивности не получишь, и сэкономишь только в случае если юзер тыкает пейджер (редко), а не в сортировку/фильтр (чаще). Причем на сортировке и фильтрации ты еще и потреяешь, т.к. базе надо сканить больше данных. Универсальность такого решения тоже под вопросом: у него все равно есть предел по количеству входных данных, пусть и в несколько раз побольше.
Я делал универсальное решение - переключать режимы грида на лету. Источник возвращает столько данных, сколько считает разумным. Также опционально считает count. А если хочет - возвращает все. Если вернули все - переключаемся в клиентский режим, где можем сортировать и дофильтровывать (т.е. сужать фильтр) без участия сервера. Типа набрали "сер" - сходили на сервер, он отдал все подходящие 60 строк, скинули на клиент, и дальше можем дофильровать до "сервера" или "сервисы" автономно.
Если вернули больше страницы - можем листать страницы на клиенте в этих рамках. Сортировать не можем. Дофильтровывать можем если получается больше страницы данных.
Также, если нам не вернули count, то мы заменяем пейджер с 1,2,3..6,7 на 1,2,3..6,show more. Ну и еще куча всяких тонкостей.
Так все вообще прикольно пашет, но я не видел таких готовых решений.