|
|
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
Мне нужно получить большое число строк (тысячи, десятки тысяч) и отобразить их постранично. Погуглил, как правило ссылаются на книжку « The Underground PHP and Oracle Manual ». В книжке есть раздел «Limiting Rows and Creating Paged Datasets», суть решения заключается в следующем: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. Честно говоря, выглядит как-то топорно — два вложенных запроса, чтобы ограничить выборку пронумерованными строками сверху и снизу. Это оптимальный способ или есть другие решения? Например в десктопных приложениях можно не закрывать курсор и при переходе по страницам результатов просто фетчить соответствующий диапазон записей. Возможно ли что-то такое в веб-приложениях? ________________________ Мы смотрим с оптимизмом... ...в оптический прицел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 10:59 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
Alibek B. два вложенных запросаты тут вокруг этого запроса столько букв написал, что хватит на сорок запросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 11:25 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
лимит кляуза, у меня Oracle 10g, в нем нет LIMIT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 11:49 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
Alibek B., оптимальным было бы сделать демона, например, на Java и такие чтобы такие данные отдавал он, а он сам чтобы отдавал номер своего двунаправленного курсора и требуемые данные и закрывал эти курсоры по настраиваемому таймауту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 13:06 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
Думаю что это для меня будет сложно. А насколько приемлемо следующее решение? Я создаю две новых таблицы, SEARCH_SET и SEARCH_CACHE. При каждом запросе я добавляю в SEARCH_SET новую запись (или ищу существующую запись с аналогичными критериями) и получаю PK для добавленной или найденной записи (SEARCH_ID). Результаты запроса я сохраняю в SEARCH_CACHE, добавляя к ним SEARCH_ID. Отображение и навигацию я осуществляю с использованием SEARCH_CACHE. В SEARCH_SET также фиксируется дата добавления/обновления результатов, чтобы очищать просроченный кеш. Заодно наличие такой таблицы сильно упростит подсчет количества строк в результате (чтобы правильно отобразить пагинацию). Или это неправильно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 14:22 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
Alibek B.лимит кляуза, у меня Oracle 10g, в нем нет LIMIT. в десятке есть аналитика что мешает использовать напр row_number/rank? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 15:14 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
Ну что вы, это же не чистое решение, один подзапрос вместо двух. А надо без подзапросов !!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 15:23 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
<мой SQL-запрос> — достаточно тяжелый запрос, который выполняется несколько десятков секунд и возвращает много строк. Мне почему-то кажется, что если вложить такой запрос в два внешних запроса (или даже один внешний запрос с аналитикой), то это скорость выполнения не увеличит. То есть при листании страниц с результатами на каждой странице я буду дважды выполнять этот тяжелый запрос (первый раз с count(*), чтобы посчитать число результатов, второй раз вложив во внешний запрос, чтобы получить строки для выбранной страницы). Если использовать сохранение результатов запроса во временной таблице (в кеше), то листание страниц и подсчет количества результатов станет тривиальной операцией и некоторые сложности могут быть только с правильным сбросом кеша. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 16:44 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
Alibek B.<мой SQL-запрос> — достаточно тяжелый запрос, который выполняется несколько десятков секунд и возвращает много строк. Мне почему-то кажется, что если вложить такой запрос в два внешних запроса (или даже один внешний запрос с аналитикой), то это скорость выполнения не увеличит. То есть при листании страниц с результатами на каждой странице я буду дважды выполнять этот тяжелый запрос (первый раз с count(*), чтобы посчитать число результатов, второй раз вложив во внешний запрос, чтобы получить строки для выбранной страницы). Если использовать сохранение результатов запроса во временной таблице (в кеше), то листание страниц и подсчет количества результатов станет тривиальной операцией и некоторые сложности могут быть только с правильным сбросом кеша. в кеше всеравно надо пронумеровать я не предлагаю для каждой странички перевыполнять запрос хотя так более правильно не знаю как у Вас с постановкой напр в результате запроса 100страниц я смотрю долго первую потом хочу посмотреть вторую, за время просмотра она ж может изменится что отобразите на екране? если "кешировать", то не в БД, ето ж накладно, напр будут пухнуть логи ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 17:28 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
Alibek B., Вообще есть result_cache для этого. Просто в подзапросе добавить хинт result_cache и оракл сам остальное сделает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 18:14 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
xtenderAlibek B., Вообще есть result_cache для этого. Просто в подзапросе добавить хинт result_cache и оракл сам остальное сделает не понял, считал что result_cache относится к функциям ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 18:22 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
Постраничный вывод в нынешних реалиях уже не предмет переживаний. Закачивай в паямять сервера приложений или клиента тысячу строк и вари как хочешь. Больше строк просматривать, жмакая ..2..3..99, смысла нет. Это либо сплошная выгрузка для обработки внешними инструментами либо аналитические кубики, отображающие агрегированные итоги. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 18:32 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
xtenderВообще есть result_cache для этого. Не знал про такое. Да, похоже что велосипед изобретать не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2016, 21:46 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
Посоветуйте, как лучше сделать? Допустим запрос возвращает 200 строк. В форме поиска кроме критериев поиска также можно указать, сколько результатов должно быть на одной странице: 10, 25, 50, 100 или все. Допустим было выбрано 25 — значит получится 8 страниц с результатами поиска. Допустим выбрана страница 3, строки с 51 по 75. Затем в форме поиска я указываю вывод по 50 результатов на страницу. Где правильнее оказаться, на странице 3 со строками 101-150 или на странице 2 со строками 51-100? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 15:38 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
Alibek B.лимит кляуза, у меня Oracle 10g, в нем нет LIMIT. xtenderAlibek B., Вообще есть result_cache для этого. Просто в подзапросе добавить хинт result_cache и оракл сам остальное сделает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2016, 09:18 |
|
||
|
Вопрос по pagination
|
|||
|---|---|---|---|
|
#18+
xtenderВообще есть result_cache для этого.Клиентский кеш на странички резать не представляю как. А серверный - если объем небольшой, то проще его весь на клиента выгрузить, сети нынче "резиновые". Если большой, то поможет только для небольшого количества клиентов. Иначе никакой памяти на сервере не напасешься. К тому же, получение первой страницы может выполняться в порядке индекса, последующие страницы незачем через кеш прокачивать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2016, 12:45 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39323285&tid=1887253]: |
0ms |
get settings: |
5ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
183ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 200ms |
| total: | 480ms |

| 0 / 0 |
