Oracle подскажите выход

← →
Demo (2013-09-11 09:31) [0]

Добрый день!

Имеется запрос в Oracle, который выполняется из проекта в Delphi.
Из за того, что запрос возвращал большое количество записей, я сделал возможность вывода определенного количества строк а в запросе урезал
rownum < count. Теперь стоит задача, что бы пользователь мог указать 5000 записей, а затем нажать "далее" и отобразить след. 5000. Есть компоненты в Delphi которые могут такое, но для этого нужно опять же загрузить все записи из базы, что очень долго. Подскажите как решить такую задачу ?

← →
macrodens © (2013-09-11 09:41) [1]

cxGrid (свойство GridMode) из палитры DevExpress умеет выводить нужное количество строк и при скроллинге догружать данные.
Также можно сделать именно запросом, не знаю как в Oracle, но в MySQL можно указать так:
select <FIELD_LIST> from <you_table> limit a,b,
где a - начальная строка, b - количество строк

← →
[ВладОшин] © (2013-09-11 10:22) [2]

// Oracle Data Access Components
// Copyright (c) 1998-2009 Devart. All right reserved.

oq1: TOraQuery;

>> я сделал возможность вывода определенного количества строк
oq1.FetchRows := определенного количества строк ;

>> Теперь стоит задача, что бы пользователь мог указать 5000 записей, а затем нажать "далее" и отобразить след. 5000.
oq1.FetchRows := 5000;

как только будет запрос 5001ой строки, автоматом подгрузится следующая порция, в колве oq1.FetchRows записей

← →
Кщд (2013-09-11 10:23) [3]

>Demo (11.09.13 09:31)
http://lmgtfy.com/?q=oracle+paging+example

← →
antonn © (2013-09-11 10:43) [4]

> как только будет запрос 5001ой строки, автоматом подгрузится
> следующая порция, в колве oq1.FetchRows записей

результат запроса оно еще хранит на сервере или при каждом "листании" запрос заново работает?

← →
[ВладОшин] © (2013-09-11 10:45) [5]

> при каждом "листании" запрос заново работает?

нет,
запрос заново не отрабатывает

← →
Demo (2013-09-11 10:52) [6]

Спасибо за столько быстрые ответы. Сейчас буду пробовать.

← →
antonn © (2013-09-11 11:00) [7]

> нет,
> запрос заново не отрабатывает

а результат хранится пока есть конекшн или по времени? (id его нужно хранить?)

← →
[ВладОшин] © (2013-09-11 11:08) [8]

> результат хранится пока есть конекшн или по времени?

пока жива сессия (oq1.Session := os1; // os1: TOraSession;)

← →
Кщд (2013-09-11 15:00) [9]

>[ВладОшин] © (11.09.13 11:08) [8]
как бы не попасть в ад: ORA-01555

← →
Sergey13 © (2013-09-11 15:23) [10]

А если, как вариант, использовать временную таблицу? Заполнил один раз и крути как хочешь хоть всю сессию.

← →
Кщд (2013-09-11 15:29) [11]

>Sergey13 © (11.09.13 15:23) [10]
это крайнее средство, когда не удаётся реализовать пейджинг штатными средствами - запросом.

← →
[ВладОшин] © (2013-09-11 15:29) [12]

>> как бы не попасть в ад: ORA-01555

Ну надо просто представлять для чего эта интерактивная функция,
что можно давать делать, что нет.

Если, допустим, форма справочники смотрит - то пусть смотрят. Они меняются раз в пятилетку. Или Если, допустим, платежи смотрят - то пусть смотрят. Они не меняются, только добавляются.
ну и oq.FetchAll := true, тоже можно. Пусть все берет, если уверен.

← →
Кщд (2013-09-11 15:39) [13]

>[ВладОшин] © (11.09.13 15:29) [12]
зачем всё это, когда можно запросом?)

← →
antonn © (2013-09-11 17:40) [14]

> это крайнее средство, когда не удаётся реализовать пейджинг
> штатными средствами - запросом.

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

← →
Dennis I. Komarov © (2013-09-11 20:28) [15]

на кой юзеру даже 5000 записей?

← →
antonn © (2013-09-11 20:59) [16]

> на кой юзеру даже 5000 записей?

чтобы выполнить гибкую сортировку, группировку и фильтрацию на клиенте

← →
Dennis I. Komarov © (2013-09-11 21:08) [17]

> чтобы выполнить гибкую сортировку, группировку и фильтрацию
> на клиенте

Вот поди нужна одна (две, три)...

← →
Пит (2013-09-11 21:16) [18]

> нет,
> запрос заново не отрабатывает

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

← →
Кщд (2013-09-11 22:25) [19]

>antonn © (11.09.13 17:40) [14]
>в данном случае это не просто запрос, это хранение результата запроса.
где это сказано?

>antonn © (11.09.13 20:59) [16]
>чтобы выполнить гибкую сортировку, группировку и фильтрацию на клиенте
зачем, если есть возможность сделать тоже самое, но на актуальных данных?
вопрос в "Dennis I. Komarov © (11.09.13 20:28) [15]" категорически логичен, коли речь идёт о 5e3 записей только на ОДНУ страницу
итак, зачем что-либо кэшировать, когда можно получить ровно то, что нужно, и актуально на данный момент?

← →
Кщд (2013-09-11 22:27) [20]

>Пит (11.09.13 21:16) [18]
>Но вот что результаты могут вычисляться по мере фетчинга
да, это "косяк" транзакционной модели Oracle.

>Собственно, от этого даже может зависеть план.
не "догнал", от чего может зависеть план в данном случае?

← →
Dennis I. Komarov © (2013-09-11 22:39) [21]

> вопрос в "Dennis I. Komarov © (11.09.13 20:28) [15]" категорически
> логичен, коли речь идёт о 5e3 записей только на ОДНУ страницуитак,
> зачем что-либо кэшировать, когда можно получить ровно то,
> что нужно, и актуально на данный момент?

более этого, бегать по страницам в 5000 записей во временном разрезе базы...

← →
antonn © (2013-09-11 22:59) [22]

> где это сказано?

выше полистай

> зачем, если есть возможность сделать тоже самое, но на актуальных
> данных?

потому что на клиенте это может быть гибче и быстрее в силу того что данные уже сформированы

← →
Dennis I. Komarov © (2013-09-11 23:09) [23]

> потому что на клиенте это может быть гибче и быстрее в силу
> того что данные уже сформированы

пример?

← →
antonn © (2013-09-12 09:25) [24]

> пример?

например посмотри возможности GridEx (сортировка, фильтры, группировка перетаскиванием) и прикинь как можно быстро и удобно пользователю забабахать консолидацию с нужными ему фильтрами (которые могут переключаться тут же на разное поведение (исключая символы, включая их, в начале/конце и тп)), сортировками по нужным столбцам в нужных направлениях, меняя местами колонки как захочется. Плюс сохранить эти настройки и подгружать как рабочую область - гибкий юзерфрендли требующий только толстый клиент и память, но не требующий внесение изменений в базу (запрос/процедуру, например не надо протаскивать имя поля и направление для сортировки). И все это на данных которые для сервера - куча строк, которые могут выбирать сложной хранимкой минут 5: выбрал, отдал, а клиент их посмотрит в том виде, в каком он удобнее для себя настроил грид.

← →
[ВладОшин] © (2013-09-12 09:47) [25]

> пример?

15 соединений таблиц, в т.ч. по функции, на 2-3 минут времени.
итог - порядка 1000 записей
вывод на экран - 10 записей
Теперь пользователь захотел немного в ином разрезе посмотреть, группировку сменить, некоторые скрыть. Опять 2-3 минуты ждать?

> Кщд (11.09.13 15:39) [13]
> >[ВладОшин] © (11.09.13 15:29) [12]
> зачем всё это, когда можно запросом?)

иногда проще бывает, особенно в условиях цайтнота

← →
[ВладОшин] © (2013-09-12 09:49) [26]

Zeitnot*
когда некогда, короче :)

← →
Кщд (2013-09-12 10:00) [27]

>antonn © (11.09.13 22:59) [22]
>выше полистай
полистал
можно цитату, в которой указывается на необходимость сохранять результат и - затем - листать именно его?

>потому что на клиенте это может быть гибче и быстрее в силу того что данные уже сформированы
на клиенте быстрее, чем SQL-запросом?
в общем случае, спорное утверждение

в общем и целом, при эффективно написанном запросе, правильный ответ: pagination средствами Oracle.
остальное - костыли, которые могут привести к появлению "фантомных"(реально отсутствующих в базе) записей в отчёте и очень неприятным exception, ломающим отчёт полностью.

← →
antonn © (2013-09-12 10:13) [28]

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

нет нельзя, потому что о необходимости речи не шло

> на клиенте быстрее, чем SQL-запросом?

не надо путать выбранные данные и их представление. Хотя в большинстве случаев быдлокодеры конечное представление ограничивают условиями выборки в запросе, это не является гибким и универсальным решением :)

← →
Кщд (2013-09-12 10:20) [29]

>antonn © (12.09.13 10:13) [28]
складывается ощущение, что ведёте разговор с собой, обсуждая выдуманные Вами ограничения и потребности ТС
появляются какие-то хранимки, работающие по 5мин, какие-то странные филосовствования на тему "быдлокодеров" и пр.
видимо, ключевое слово rownum в первом посте ТС, Вам ничего не говорит
так я намекну: у ТС запрос
запрос, результаты которого он желает листать по 5 000 записей
про фильтры и кастомные сортировки у ТС ничего не было сказано - это всё Ваши домыслы

← →
Кщд (2013-09-12 10:20) [30]

*философствования)

> Кщд (12.09.13 10:20) [29]

вы знаете сколько выполняется запрос у ТСа и какую нагрузку он дает? :) если нет, то - [14], потому что вы именуете "запросом" на самом деле есть нативное [10] судя по [7]+[8]. Я достаточно полно восстановил цепочку, которую вам трудно было отследить? :)

> про фильтры и кастомные сортировки у ТС ничего не было сказано
> - это всё Ваши домыслы

ТС тут не причем, это было к [15], всего лишь на предыдущей странице

← →
Кщд (2013-09-12 12:25) [32]

>antonn © (12.09.13 10:37) [31]
>потому что вы именуете "запросом" на самом деле есть нативное [10]
нативное для чего?)
что вообще за поток сознания?)
запросом я именую то, что начинается с select, а Вы?)
сформулируйте мысль чётко
глобальные временные таблицы - это весьма native-инструмент Oracle, открытый курсор - тоже вполне себе "нативно", вот только это не одно и то же
Вы берётесь рассуждать о вещах, в которых не смыслите

> запросом я именую то, что начинается с select, а Вы?)

а мы смотрим глубже того, что начинается с select. точнее даже чем оно заканчивается :)

← →
Кщд (2013-09-12 12:42) [34]

>antonn © (12.09.13 12:34) [33]
>а мы смотрим глубже того, что начинается с select.
а, любители сферических коней)
по теме: в чём недостатки организации pagination с помощью аналитических ф-ций(или rownum) в Oracle?
лучше с помощью кода, а не общих бессмысленных фраз типа "а мы смотрим глубже того, что начинается с select"

> по теме: в чём недостатки организации pagination с помощью
> аналитических ф-ций(или rownum) в Oracle?

каков ответ на [4]?

← →
Кщд (2013-09-12 13:01) [36]

← →
Кщд (2013-09-12 13:02) [37]

> 1. запрос не проходит стадию parse;
> 2. результат запроса, в общем случае, не хранится.

это идет вразрез с [5], если результат запроса не хранится, значит при "пейджинге" запрос отрабатывает еще раз?

← →
Кщд (2013-09-12 13:38) [39]

>antonn © (12.09.13 13:10) [38]
>это идет вразрез с [5], если результат запроса не хранится, значит при "пейджинге" запрос отрабатывает еще раз?
запрос может находиться в одной из трёх фаз: parse, execute, fetch.
что значит для Вас фраза: "запрос отрабатывает еще раз"?
очень жаль, что Вы не владеете элементарной терминологией

← →
Кщд (2013-09-12 13:39) [40]

>antonn © (12.09.13 13:10) [38]
и, да - это ни с чем не идёт вразрез
просто Вы не представляете механизма работы СУБД(в данном случае - Oracle).

Oracle подскажите выход Найти похожие ветки