Каков максимальный размер внутренней таблицы?

Удав

WhiteScorpio написал:

Удав написал(а):

3.Использовать функции агрегации данных SUM, MAX и т.п. в SELECT .. GROUP BY

SUM, MAX, и другие функции зависят от нагрузки, если таблица огромна, а количество обрабатываемых данных велико (>50%), то могут возникнуть сомнения - НУЖНО ЛИ?! ОПТИМАЛЬНО?!. Т.ч. требуется уточнение или более развернутый ответ, НЕ ТАК ЛИ?!

То есть Вы не верите рекомендациям SAP

Понятно, что агрегацию нужно использовать с умом.
Например при подсчете данных в контроллинге по малому числу параметров (Период+Вид затрат+операция CO) использование агрегации COSS и COSP дает заметный выигрыш по времени в сравнении c обработкой данных через FOR ALL ENTRIES или SELECT ...PACKAGE SIZE из-за того, что резко уменьшается объем передаваемых на сервер приложений данных.

WhiteScorpio

Удав написал(а):

WhiteScorpio написал:

Если PACKAGE SIZE использовать для FOR ALL ENTRIES, то ДА (как я считаю), а для другого?! Можете пояснить?

Как раз PACKAGE SIZE для FOR ALL ENTRIES не нужен.
PACKAGE SIZE разбивает выборку во внутреннюю таблицу на указанное количество записей и должен использоваться для обработки записей порциями.
Преимущества:
1.Фиксированный размер внутренней таблицы, т.е. возможность последовательной обработки данных без увеличения потребляемой памяти
2.Уменьшение количества запросов к БД по сравнению с FOR ALL ENTRIES
Недостатки:
Обработка должна быть достаточно быстрой, т.к. ENDELECT никто не отменял. :wink:

Да, Удав, согласен, я ошибся с PACKAGE SIZE. Спсибо, за аргументы.
Если нужна последующая агрегация данных, то ответ, Удава, дополнить нечем.
Если хранение и вывод, то...

WhiteScorpio

Удав написал(а):

SUM, MAX, и другие функции зависят от нагрузки, если таблица огромна, а количество обрабатываемых данных велико (>50%), то могут возникнуть сомнения - НУЖНО ЛИ?! ОПТИМАЛЬНО?!. Т.ч. требуется уточнение или более развернутый ответ, НЕ ТАК ЛИ?!

То есть Вы не верите рекомендациям SAP

Понятно, что агрегацию нужно использовать с умом.
Например при подсчете данных в контроллинге по малому числу параметров (Период+Вид затрат+операция CO) использование агрегации COSS и COSP дает заметный выигрыш по времени в сравнении c обработкой данных через FOR ALL ENTRIES или SELECT ...PACKAGE SIZE из-за того, что резко уменьшается объем передаваемых на сервер приложений данных.[/quote]

Да нет. Не воспринимай так близка к сердцу. Итак, что я имею ввиду: использование математических функций стоит определить по размеру таблицы и проценту выбора (примерное соотношение выбираемые записи/общее количество). Если таблица не маленькая, что в полне вероятно, + не малое количество данных (по условию падает в дамп (исключение: до данного SELECT'а память уже забита)), томатематические функции лучше делать на application server. Но если SAP говорит, то пусть так и будет. Я от SAP'a тоже много чего услышал полезного, но то о чем я пишу из личного опыта. Хотя у каждого своя голова на плечах.

Good luck.

Пономарев Артем

Я, конечно, извиняюсь, но где в вопросе намек на агрегаты в принципе?

По моему автор вопроса давно услышал то, что хотел.

Продолжая дискуссию:
собственно

Code:

SELECT ... PACKAGE SIZE ... ENDSELECT

я и не рассматривал, поскольку есть более стабильная альтернатива в виде

Code:

OPEN CURSOR ... WITH HOLD

По поводу агрегатов: В общем случае на 100% уверен, что выполнение только агрегатных функций на уровне СУБД будет быстрее, чем на уровне сервера приложений. Независимо от структуры и объема данных.

WhiteScorpio

Пономарев Артем написал:

Я, конечно, извиняюсь, но где в вопросе намек на агрегаты в принципе?

По моему автор вопроса давно услышал то, что хотел.

Продолжая дискуссию:
собственно

Code:

SELECT ... PACKAGE SIZE ... ENDSELECT

я и не рассматривал, поскольку есть более стабильная альтернатива в виде

Code:

OPEN CURSOR ... WITH HOLD

По поводу агрегатов: В общем случае на 100% уверен, что выполнение только агрегатных функций на уровне СУБД будет быстрее, чем на уровне сервера приложений. Независимо от структуры и объема данных.

Пустая тема, каждый на своем стоит.

Good luck.

Правила форума

Каков максимальный размер внутренней таблицы?

Кто сейчас на конференции