всем привет

такая задача:

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

в голову приходят следующие варианты:

1) загружать все целиком, и показывать необходимую страницу, храня общий список в List d синглтоне и обновляя по мере необходимости

+просто, быстрая работа
- неудобно будет делать выборки по нескольким сложным критериям - добавляется дополнительный громоздкий анализ
- очевидно, при большом количестве записей заметно отожрется память (возможно, на данный момент не такая уж серьезная проболема)
- сложность с обновлениями, методы доступа к данным должны быть синхронизированы для того, чтобы избежать конфликтов при чтении обновляемых данных, таким образом, во время обновления для всех пользователей ресурс будет недоступен, что не есть гуд, особенно если записей много и обновление займет значительное время


2) получать ResultSet, затем, по мере выбора страниц скролить его, динамически подгружая новые
+ не весь селект целиком
- хранение незакрытого rs в сессии, что при множестве пользователей быстро убьет датасурс и будет зело жрать память
- невозможно применить удобный паттерн "Session per request" - когда пользовательская сессия в ThreadLocal закрывается фильтром после отправки ответа на пользовательский запрос
- опять же сложно определить грамотную политику обновлений, т.е. когда система должна решить, что текущий rs неактуален и пересоздать его.
имхо маложизнеспособный вариант

3) делать запрос целиком, но загружать rs только до требуемой страницы, затем закрывая rs (упрощенный вариант №2)

+ простая реализация
- придется все равно грузить кучу ненужных данных, особенно если пользователь захочет просмотреть последние страницы

4) юзать предоставляемую некоторымы БД возможность выборок "от... до..."

+ идеальный вариант
- не все субд так умеют. не знаю, поддерживается ли это на уровне HQL (предполагается использовать хибер), хотя думаю, что да.

пока что все
ваши варианты, господа?

Мы реализовывали именно четвертый вариант, но у нас было дополнительное условие - ограниченность ресурсов (в память могло загружаться не более 500 записей).

Это сообщение отредактировал(а) Lamer George - 18.11.2005, 13:10

четрвертый - вообще супер
но хотелось бы отвязаться от конкретной БД, если этого можно достичть малой кровью

Это сообщение отредактировал(а) Souljah - 18.11.2005, 13:20

Я испоьзую 3, только не вычитываю,а ставлю курсор на нужную запись! это требует JDBC 2 и все...

Цитата

Я испоьзую 3, только не вычитываю,а ставлю курсор на нужную запись! это требует JDBC 2 и все...

с какими параметрами создается resultSet чтобы данные не тянулись при скролле?

Я обычно использую 4-й способ, то есть "от и до". В постгрессе такое делается - просто сказка. В других СУБД - через два вложенных селекта. А кто вложенные селекты не поддерживает, тех я даже и за СУБД не считаю

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

Поэтому я реализовал следующую стратегию: в запросе выбирал только ID нужных записей и сохранял в обычном списке, а список - в мапе, ключом к которому было собственно условие запроса. При этом я, естественно, имел возможности обрубать длинные ResultSet'ы при превышении разумного размера.

Когда юзер тыкал в очередную страницу, то система, видя, что список ID для данного условия уже сгенерирован, просто брала соответствующую порцию и с этими ID уже шла в базу и добирала остальную инфу, необходимую для формирования бизнес-сущностей.

Компонент, который отвечал за хранение выборок, следил также за размером мапа, и при переполнении выкидывал наиболее давно не использумую выборку (стратегия LRU). Ничего страшного при этом не происходило: если какой-то юзер заснул у себя за компом, а потом проснулся, а результатов в кэше уже нет - ну и пофиг, сгенерируем всю выборку заново, он даже и не заметит.

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

Цитата

Я испоьзую 3, только не вычитываю,а ставлю курсор на нужную запись! это требует JDBC 2 и все...

-не понял!
У меня данные выгребает сессион бин....
отослал я клиенту 100 записей - запомнил де курсор..
но ведь не факт , что при следующем запросе - я попаду на этот же бин...
или я чегой то недопонял.


мы 4 вариант стараемся юзать ....

Цитата(Stampede @ 18.11.2005, 19:31)

В постгрессе такое делается - просто сказка. В других СУБД - через два вложенных селекта.

PostgreSQL просто скрывает это от программиста. Выборка записей с i по j имеет смысл только если порядок записей фиксирован, а это достижимо только в результате предварительной сортировки.