Выбор записей из таблицы произвольным запросом

[mazzy]

Цитата:

Сообщение от sukhanchik

В этом случае я сначала задаю уточняющие вопросы. Хотя тут они уже были заданы и без уточнений можно долго разглагольствовать . Нужен автор с более детальным примером .

согласен )

Цитата:

Сообщение от sukhanchik

InventTrans
В свое время (АХ 4.0) у меня была задача поиска "закольцованных" движений. Соответственно, чтобы понять "кольцо" - нужно для каждой записи (каждого типа движения) применить свой алгоритм обработки. На выходе может получиться неопределенно много записей и тривиальный фильтр не подходит, соответственно ссылку на RecId найденных записей было удобно записывать в RecordReference_RU, а затем открывать стандартную форму InventTrans, отфильтрованную по отобранным движениям.

закольцованные через inventSettlement? тогда нужно больше одной таблицы )))
или ты лот возврата имеешь в виду. а как у него кольцо может образоваться?

Цитата:

Сообщение от Maxim Gorbunov

Вместо того, чтобы возвращать записи, упаковкнные в какой-то контейнер, можно возвращать сформированный запрос. Например, в виде объекта Query или QueryRun.

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

хотя если можно использовать больше одного датасорса по одной таблице... )))

Цитата:

Сообщение от S.Kuskov

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

А объектно-ориентированное программирование? Не? )))

Один класс инкапсюлирует одно, другой класс - другое. они могут использовать друг-друга.

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

но надо оптимизировать не запрос. а систему в целом. которая работает в многопользовательском режиме.

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