Пейджинговый запрос — это часто встречающаяся проблема. Давайте сначала посмотрим, почему существует пейджинговый запрос:
Удобство пользователя: пользователи не могут просматривать все данные одновременно, поэтому лучше просматривать страницу за страницей.
Повышение производительности: получение всех данных из базы данных одновременно будет медленнее.
Итак, теперь позвольте мне попытаться опровергнуть приведенные выше доводы:
действительно ли это удобно? Мы рассматриваем следующую ситуацию, если имеется только 20 фрагментов данных.
Если данные превышают 1000 элементов.
Очевидно, что первый тип не требует пейджинговых запросов. Странно то, что второй не нужен, потому что ни один пользователь не желает перелистывать страницу за страницей до конца. Если данные, которые запрашивает пользователь, выходят за пределы диапазона данных, который его волнует, я думаю, ему следует разрешить повторный ввод. условия запроса, как у нас. То же, что и при использовании Google.
Но что касается дружественного интерфейса приложения, мы всегда надеемся, что пользователь сможет полностью понять результаты своего запроса, поэтому необходимо сказать пользователю: «Сколько данных вы нашли? Однако в настоящее время могут быть отображены только первые 1000 элементов. Если вы хотите просмотреть все данные, что тогда следует сделать..."
Улучшится ли производительность?
Если объем данных невелик, очевидно, что производительность существенно не улучшится. Наоборот, производительность значительно снизится. Потому что база данных выполняет ненужные запросы и условия запроса.
Если объем данных большой, производительность может существенно не улучшиться, потому что всегда приходится выполнять дополнительный запрос подсчета, а при объединении SQL с большой вероятностью произойдет полное сканирование таблицы. Конечно, это зависит от принципа реализации базы данных.
Можно представить, что зависимость между влиянием пейджинговых запросов на производительность и объемом данных должна представлять собой кривую. Когда объем данных мал, производительность будет снижаться, а когда объем данных велик, производительность. может (в зависимости от разных баз данных) быть улучшено. Ключевым моментом является нахождение точки перегиба кривой путем тестирования. Производительность получается не на основе опыта и ощущений, а путем тестирования. К тому же, если вынуть все данные сразу, это действительно повлияет на производительность пространства. Однако память сейчас очень дешева...
Негативное влияние Для хорошо спроектированного веб-приложения действительно неудобно передавать pageNo и PageSize между различными классами. Эти два данных, очевидно, принадлежат уровню представления. Конечно, если вы используете RoR, я об этом не упомянул.
Значительно увеличивает сложность программирования, особенно если учесть независимость базы данных.
Странное явление: почему большая база данных не предоставляет запросы на подкачку напрямую? RowNo в Oracle не используется для подкачки, равно как и Top в SQLServer.
в заключение
ExtremeTable, DisplayTag и JSF DataTable предоставляют простые методы разбивки по страницам, то есть разбивку по страницам в коллекции результатов. Он очень удобен в использовании и проясняет логику, что значительно повышает эффективность работы. В большинстве случаев этот метод можно использовать напрямую.
Если в ходе тестирования вы обнаружите, что описанный выше метод влияет на производительность, рассмотрите возможность использования запросов на подкачку.
Для приложений с большим количеством пользователей также можно рассмотреть пейджинговые запросы из-за ограничений памяти. Однако лично я рекомендую метод кэширования: тот же запрос помещается в кеш...
Используйте разумный дизайн, чтобы оградить разработчиков от необходимости иметь дело с логикой подкачки. Например, логика подкачки и запрос подсчета размещаются в родительском классе, а за объединение условий запроса отвечает разработчик. Давайте посмотрим конкретно на шаблоны проектирования.
Приглашаем всех к обсуждению! ! !