Можно ли значение нескольких вычисляемых полей запроса взять из одного массива, возвращаемого пользовательской функцией?

Ситуация такая: сделал пользовательскую функцию, которая двумя запросами (один с группировкой, другой простой) вытаскивает из двух таблиц набор данных, их между собой арифметирует и возвращает итоговый результат.

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

Для понимания - я вытаскиваю
- суммарный объем по нескольким пунктам, входящим в одну накладную,
- суммарный вес,
- разные надбавки и скидки, влияющие на цену и которые привязаны к накладной,

и на их основе рассчитываю
- приведенный объем,
- стоимость за одну операцию,
- стоимость за другую,
- стоимость за третью и
- общую окончательную стоимость.

Вот эти рассчитанные данные (штук пять-шесть) мне нужно вывести в запросе отдельными полями.

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

Мне видится это весьма расточительным делом, делать вместо двух 10-12 одних и тех же запросов.

Я могу для одной записи целевого запроса вычислить все необходимые мне возвращаемые результаты за один раз на основе двух запросов из функции и поместить их в массив. Только не соображу как мне вернуть в вычисляемые поля запроса значения элементов этого массива.

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

0

А где в дальнейшем будут использованы данные запроса?

0

Ну он достаточно базовый получается и востребован в нескольких формах (в табличном виде), ну и плюс он же используется в других запросах

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

0

Можно так попробовать:

Вложения

db1.zip (11.9 Кб, 3 просмотров)

0

Я для "сложно/долго вычисляемых значений" пользую обычно коллекции инстансов классов/текстовых значений,
в которые единожды добавляю айтемы с ключем (значение ключевого поля, обычно),
и в дальнейшем при работе приложения пользую уже данные из коллекции,
получая их по значению ключевого поля.
Главное в таком подходе - не забыть пересчитать итоговые значения, при изменении значений полей, участвующих в вычислении.

0

Правильно ли я понял:
Определяем в модуле пользовательский тип данных с нужным количеством расчетных значений, в запросе в первом вычисляемом поле обращаемся к моей пользовательской функции, которая один раз "затратно" вытаскивает исходные данные и а) заполняет пользовательский тип, который остается заполненым на уровне модуля до следующего вызова "затратной" функции; б) возвращает в поле запроса одно из значений (что бы в холостую не гонять). Остальные вычисляемые поля в запросе обращаются уже каждый к своей "легкой" функции, которая считывает и возвращает нужное значение из заполненного пользовательского типа. Следующая запись в первом вычисляемом поле опять стартует "затратную" функцию, которая переписывает пользовательский тип.
В вашем примере вроде да, все работает, завтра у себя реализовать попробую. Спасибо за подсказку!

0

Сделал по подобию вычисляемые поля в своей базе, так то считаются нормально, но столкнулся с таким явлением: если в таблице (возвращаемой запросом) выделить/поперемещаться по первому вычисляемому полю (то, которое связано с первичной "затратной" функцией), то скачут значения во всех вторичных (возвращаемых "легкими" функциями) полях выделенной записи. Скачут - это значит отображают не реальное значение а (как я понял) значение соседней записи. Если выделить поле с "легкой функцией", то значение скачет только в этом поле. Если выделить поле не с функциями а простое, возвращаемое из таблицы, то значения не скачут. Вобщем, описал как мог, но лучше посмотреть глазами, пример во вложении. В чем может быть дело?

Вложения

Database2.zip (422.0 Кб, 0 просмотров)

0

Сорри, не совсем корректный файл (исходные данные), обновленный в этом посте выкладываю

Вложения

Database2.zip (301.6 Кб, 5 просмотров)

0

yup1975, вижу вы решили поиграться с размерностью данных (Double)!
Весьма поучительно!
Но у вас в БД :
- Integer
- Long Integer
- Currency
... и фсё!
Так и зачем такие "бешеные" вычисления с данными которых у вас нет = непонятно?
Ресурсы системы некуда девать?

0

Eugene-LS, согласен что не очень хорошо, но руки не дошли вдумчиво разобраться. На вскидку, почему то криво отображает значения если переменным с дробной частью назначить Single. В этом случае цифры получаются вида 0,720000028610229, даже если к ним применить Round, что режет глаз. Currency попробовал всем проставить - для денег самое то (ну собственно для них и предназначено), а вот для других значений (например для объема) не по феншую выводит 0,72р. Понятно что в целевом месте отформатирую как нужно, но что то глаз режет И Currency же тоже 8 байт, как и Double, реально легче с ними оперировать машине?

0

Сообщение от yup1975 Вот эти рассчитанные данные (штук пять-шесть) мне нужно вывести в запросе отдельными полями.

куда вывести
- сначала в запрос
- а потом и в отчет

может вам методику расчета поменять - считать все это в форме

0

yup1975, если выполнение запроса не требует очень быстрого ответа, то можно поставить дистинкт (неявная группировка) и ничего "скакать" не будет. На моей не очень быстрой машине запрос с дистинктом выполнялся 23 секунды. Что конечно намного больше исходного. Но зато правильно.

1

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

Добавлено через 1 минуту
mobile, спасибо за решение, попробую! Но интересно почему все же "скачет"

0

Сообщение от yup1975 А в запросе данные нужны для последующей группировки и получения суммарных значений в разных разрезах

одной из моих первых задач были СЧЕТА-ФАКТУРЫ
об интернете я тогда и не слышала(вернее не видела)
все итоги считала при вводе - уж очень тогда часто правила расчета тогда менялись и бухгалтерия пожелала не пересчитывать итоги по счету, только если не в контрольном режиме

поэтому все итоги считались и запоминались при вводе
соответственно все групповые итоги считались с ранее запомненных цифр

0

Да, можно и так, но имхо это не рационально. Я вот то же пойду, наверно, по пути записи и хранения в промежуточном месте этих итогов (пользователь будет с нужной периодичностью запускать запрос на обновление), но как то не нравится мне это.

0

Сообщение от yup1975 по пути записи и хранения в промежуточном месте этих итогов

вряд ли промежуточное место лучше основных таблиц

конечно многое зависит от схемы таблиц вашей базы

0

и 2 типичные формы для работы с защитой от случайной корректуры

Миниатюры

   

0