Цитата:
Сообщение от
sukhanchik
В этом случае я сначала задаю уточняющие вопросы. Хотя тут они уже были заданы и без уточнений можно долго разглагольствовать
. Нужен автор с более детальным примером
.
согласен )
Цитата:
Сообщение от
sukhanchik
InventTrans
В свое время (АХ 4.0) у меня была задача поиска "закольцованных" движений. Соответственно, чтобы понять "кольцо" - нужно для каждой записи (каждого типа движения) применить свой алгоритм обработки. На выходе может получиться неопределенно много записей и тривиальный фильтр не подходит, соответственно ссылку на RecId найденных записей было удобно записывать в RecordReference_RU, а затем открывать стандартную форму InventTrans, отфильтрованную по отобранным движениям.
закольцованные через inventSettlement? тогда нужно больше одной таблицы )))
или ты лот возврата имеешь в виду. а как у него кольцо может образоваться?
Цитата:
Сообщение от
Maxim Gorbunov
Вместо того, чтобы возвращать записи, упаковкнные в какой-то контейнер, можно возвращать сформированный запрос. Например, в виде объекта Query или QueryRun.
да, но тут снова встает ограничение аксапты - на одно поле - одна агрегатная функция.
в результате получить отдельно дебетовые и кредитовые обороты в одном запросе по одной таблице становится проблематично.
хотя если можно использовать больше одного датасорса по одной таблице... )))
Цитата:
Сообщение от
S.Kuskov
Более общая формулировка задачи:
Как (с минимальными накладными затратами) результат (выход) одного алгоритма подать на вход следующего, так что бы алгоритмы не зависили от тонкостей реализации друг друга. Общего рецепта по-видимому нет. Когда-то будут более выгодны временные таблицы, когда-то квазивременные
А объектно-ориентированное программирование? Не? )))
Один класс инкапсюлирует одно, другой класс - другое. они могут использовать друг-друга.
тут вопрос оптимальности и нагрузки на базу.
очень многие люди считают, что один монстр-запрос будет работать оптимальнее.
поэтому не разбивают на классы.
но надо оптимизировать не запрос. а систему в целом. которая работает в многопользовательском режиме.
если рассматривать систему в целом, то монстр-запросы как правило очень плохо влияют на среднюю отзывчивость сервера и среднюю производительность. в среднем лучше на SQL подавать несложные и однотипные запросы. даже если при этом получаются не самые минимальные resultSet'ы.