Нарастающий итог

[Mikle Klementiev]

Вопрос по оптимизации

Есть табличка. Для простоты - одно поле ( VALUE), Integer
Задача - посчитать нарастающий итог
то есть, результат запроса должен выглядеть следующим образом:

Value narast_itog
+1 1
+3 4
+5 9
-3 6
-2 4

и т.д.

В реальности в таблице много полей и условие выборки задается по разным полям с разными условиями. По этому никогда заранее не известно значение WHERE ..... в операторе SELECT - как следствие -
приходится его формировать динамически, в программе ( Delphi 7.0).

Вопрос - как добиться максимального быстродействия? Желательно без создания временных рабочих таблиц.

[Slava Ekimov]

Вопрос по оптимизации

Вопрос - как добиться максимального быстродействия? Желательно без создания временных рабочих таблиц.

Процедурой

[Mikle Klementiev]

Вопрос по оптимизации

Вопрос - как добиться максимального быстродействия? Желательно без создания временных рабочих таблиц.

Процедурой

Процедура подразумевает, что оператор SELECT уже написан.
В моем случае, условия выборки каждый раз разные ( по разным полям, с разными условиями) То-есть заранее неизвестно, что писать в WHERE...

[Лысый]

>Mikle Klementiev
Какая версия сервера?
Ни как народ не хочет научиться оформлять вопросы...

[Mikle Klementiev]

>Mikle Klementiev
Какая версия сервера?
Ни как народ не хочет научиться оформлять вопросы...

IB server v7.5

[kdv]

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

Так вот - встречный вопрос: какой запрос и какой у него план? и насколько "динамичен" where?

[Merlin]

Вопрос по оптимизации

Есть табличка. Для простоты - одно поле ( VALUE), Integer
Задача - посчитать нарастающий итог
то есть, результат запроса должен выглядеть следующим образом:

Value narast_itog
+1 1
+3 4
+5 9
-3 6
-2 4

и т.д.

В реальности в таблице много полей и условие выборки задается по разным полям с разными условиями. По этому никогда заранее не известно значение WHERE ..... в операторе SELECT - как следствие -
приходится его формировать динамически, в программе ( Delphi 7.0).

Вопрос - как добиться максимального быстродействия? Желательно без создания временных рабочих таблиц.

С временными таблицами замучаешь сервер. И запросами с суммированием предыстории каждого шага - тоже. Если природа запроса такова, что нарастающий итог не зависит от предыстории, оставшейся за его рамками, и возвращаемый резалтсет не слишком большой, то можно на клиенте забирать его целиком во что-нибудь типа TClientDataSet и AfterOpen пробегаться по нему с накоплением суммы и Edit - Post. Если же это что-то типа складской карточки и нарастающий итог - это остаток после каждой операции, то лучше хранить его прямо в базе, поддерживая на триггерах. Или, если вернуться к решению на стороне клиента, то сначала одним запросом получить остаток на то, что не попало в запрос, но является предысторией для него, и учесть как стартовые условия для суммирования на AfterOpen. Иначе - только через ХП. В IB нет execute stament, как в FB, который хорош как раз для таких задач аналитического плана, когда потерями на перекомпиляцию динамически формируемого или передаваемого параметром с клиента запроса внутри ХП можно пренебречь. Но если диапазон изменения where не слишком всебъемлюш, можно раскрутиться на этажерке if-ов, хоть это и проктология в общем случае.