Мне надо, чтоб в запросе в поле показывалось некое значение, вычисляемое в зависимости от всех предыдущих записей этого запроса.

Например: сумма всех предыдущих значений какого-то поля.

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

А что делать, когда мне надо подсчитать сложную среднюю (всех записей выше текущей)?

Нельзя ли как-то использовать для этого хранимую процедуру?

По следующему алгоритму:

1) Объявить в хранимой процедуре глобальную переменную (можно ли?)
2) Как-то указать, чтоб запрос обрабатывался строго в порядке как указано в ORDER BY ,а не как там оптимизатору приспичит.
3) В этой переменной накапливать вычисляемое значение в порядке обработки запроса.

Вот план я составил ... но не знаю - возможно ли это?

Может не стоит и пытаться?

Есть еще план номер 2:

Я видел в документации SQL-сервера что можно создать собственную агрегатную функцию.
Но не уверен, что с её помощью можно добиться результата.
Ведь оптимизатор не сможет правильно обработать запрос с неизвестной агрегатной функцией - и будет медленно исполняться.

Может уже кто-то сталкивался с подобными проблемами?

А в чем собственно проблема?


Не правда. Необходима оптимизация структуры.


Тут совсем непонятно   

Вообщем, неплохо бы было примеры для более предметного разговора ...

А, ну версию сиквела обезательно в студию.

Это сообщение отредактировал(а) Zioma - 22.7.2009, 22:41

AndreyK, саветую вам посмотреть в сторону аналитических(оконных) функций:
http://www.sqlbooks.ru/readarticle.aspx?pa...;file=sql200523
http://www.rsdn.ru/article/db/WindowFunctions.xml

Думаю здесь курсор поможет. (На сколько я понял вопрос)(:

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

Добавлено через 4 минуты и 53 секунды

У меня как раз всё и написано с использованием курсора ...

Но из-за очень медленного механизма связи приложение-SQL-сервер, моя задача выполняется очень медленно.

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

  


неужели в MSSQL нет возможности материализовать набор к которому нужно обращаться при каждом шаге?!...

не дорос еще билли, чтобы running sum посчитать.
Кляуза order by определена только для Ranking Window Functions , не для Aggregate Window Functions 

Когда я открыл для себя это, почувствовал себя сильно обманутым :(

Это сообщение отредактировал(а) Zloxa - 24.7.2009, 22:55

не то что я сильно расстроился, но за прояснения ситуации, спасибо!

Я нашёл другое решение.

Оказывается MSSQL сильно тормозит, когда одновременно открыты два (или больше) курсоров и - главное! - в обоих происходят исправления.

Я переделал все алгоритмы, чтоб одновременно не было открыто более одного курсора.

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

И все сразу быстро заработало!

Та процедура, что раньше 20 минут выполнялась - теперь за пару секунд пролетает.