Метод работы постраничной загрузки

При использовании профайлера обнаружили следующий момент:
при установленном параметре "40 записей реестра на страницу" и постраничном пролистывании записей из базы запрашиваются не 40 записей а Top"Х", где Х ="40 * номер страницы".
Например, находясь на 9 странице записей и переходя на 10ю, вместо нужных 40 записей грузится 400 и из них выводится только 40.

На мой взгляд, это весьма не оптимальное решение постраничной загрузки, т.к. к клиенту передается большое количество ненужной ему информации. Представьте, что вы используете систему в удаленном доступе через слабый интернет-канал...
Здесь, например, приводятся методы, которые выдают клиенту только те записи, которые ему действительно нужны:
http://databases.aspfaq.com/database/how-do-i-page-through-a-recordset.html

Для SQL2005
http://www.sqlteam.com/article/server-side-paging-using-sql-server-2005

Существуют и другие методы.

Компания Террасофт прокомментировала данное решение, что иные методы (например, приведенные выше в ссылках) создают дополнительную нагрузку на сервер.

Мое мнение, что лучше пусть потрудится специализированное оптимизированное специальное, как правило, мощное железо - сервер, чем по каналам гонять такие массивы.

Вот интересно было бы узнать, а кто что думает по этому поводу?

Нравится

2 комментария

Добрый день, Александр!

Ваше замечание в некоторой мере верно. С точки зрения выбранного способа реализации, он действительно не самый лучший при работе на дальних страницах реестра. Но я бы хотел пояснить почему мы остановились именно на этом способе, ведь мы также изучали множество способов реализации постраничности.

Дело в том, что мы стараемся привить нашим пользователям культуру поиска информации через фильтрацию. Мы даём достаточно мощные возможности по поиску. В идеале нашим пользователям не должно понадобиться работать даже со второй страницей реестра. Эта была и остается наша основная идея. Но даже если ситуация не идеальна, то пользователю должно редко понадобиться переходить на указанные Вами страницы. Лично из своего опыта скажу, что я уже забыл, когда переходил на вторую страницу реестра.

При этом, если придерживаться описанной мной идеи, именно выбранный нами способ наиболее производительный, и наименее требовательный к ресурсам.

Еще одним немаловажным фактором является то, что его достаточно легко реализовать на всех поддерживаемых нами СУБД.

При работе же с использованием Web сервисов на клиент реально передается только нужная порция данных. Отбор необходимых данных выполняется на сервере, дополнительно сжимается, режется на части, и отправляется блоками. В этом отношении Web сервисы немного выигрывают.

Сергей, не могу не согласиться, что при развитии навыков рботы с системой, действительно, пролистывание страниц - категорически редко выполняемая операция.
Так же как и Вы, я не помню когда пролистывал реестр дальше 2 страницы.

Т.е. остановимся на том, что, хоть, с точки зрения абстрактной производительности, это и не самое лучшее решение, но в контексте реальной практики - весьма удачное. ))

Показать все комментарии