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

[mazzy]

Цитата:

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

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

согласен )

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

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

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

[Maxim Gorbunov]

Цитата:

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

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

По-моему, мы всё дальше уходим от исходной задачи, но я отвечу

Как и многие другие проблемы, эта решается с помощью создания промежуточных View. Во view можно сделать сколько угодно полей, которые будут разными агрегатными функциями на основе одного поля физической таблиц (см. View CustPackingSlipMinMaxDates; к сожалению, только в AX2012, но в AX2009 это тоже работает).

Правда, собрать дебет отдельно от кредита это не поможет. Тут как раз агрегатная функция одна, но фильтры разные. Но и эту задачу можно решить путём создания промежуточных View. В AX2012 во view можно добавлять computed columns, так что можно сделать View на основе базовой таблицы и добавить в него поля AmountDebit и AmountCredit, а потом суммировать их сколько угодно. В AX2009 computed columns нет, но задача, в принципе, тоже решаема, только придётся повозиться, чтобы правильно сделать cross join между двумя датасорсами, в одном из которых будут собраны дебетовые проводки, а в другом - кредитовые.

[mazzy]

Цитата:

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

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

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

Цитата:

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

раз все равно придется делать классы, отвечающие за бизнес-сущности,
то может и не заморачиваться с "произвольным запросом"
а сразу сделать нормальные классы? ))))

))))

[Maxim Gorbunov]

Цитата:

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

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

Я не очень понимаю, к чему ты ведёшь. Вероятно, это всё-таки не мне был ответ. Если ты хочешь поговорить о data entities, можно, конечно, и об этом порассуждать, только какое отношение это имеет к выбору записей из базы? Делаешь ты поверх всего этого entity или нет - логику выбора записей тебе внутри всё равно реализовывать придётся.

Комбинироваться эти view могут с помощью других view, и таких примеров уже очень много в стандартном приложении. Посмотри, например, на View InventValueTransView, который собирается (через View InventValueTransUnionAll) из нескольких других View, которые в основе своей имеют InventTrans и InventSettlement, отфильтрованные по разным наборам критериев.

Скажу так: за бизнес-сущность вовсе не обязан отвечать класс. Это может быть и View, и Query. Ну или правильнее будет сказать, что класс, отвечающий за бизнес-сущность - это совсем не обязательно класс в смысле объекта AOT типа "класс".

P.S.: Я, наверное, дальше в этой ветке буду только на прикладные вопросы отвечать. Абстрактные идеологические рассуждения, конечно, тоже иногда интересны, но, пожалуй, не сегодня

[S.Kuskov]

Цитата:

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

Понятно. Я думал, while select что-то такое умеет, чего не умеет Query, но while select тоже не умеет case when.

Хотите таких примеров? Их есть у меня Сортировка Query
практический пример Добавление даты из партии в форму в наличие

[Logger]

Цитата:

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

Хотите таких примеров? Их есть у меня Сортировка Query
практический пример Добавление даты из партии в форму в наличие

Еще в копилку
noFetch в Query(Run)

[sukhanchik]

Цитата:

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

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

InventSettlement тут ни при чем. Да, тут будет 2 таблицы - если еще считать InventDim. Но RecId из InventDim обычно никому неинтересны, в отличие от RecId из InventTrans.
Речь идет о переносе товара между складами, когда товар со склада А переносится
на склад Б, с Б на В, с В на Г и т.д. А потом где-то с Ж снова на А или на Б. А теперь представим себе, что у нас помимо склада еще есть что-нибудь типа номера ГТД и/или партии и ... далее по списку аналитик.

В 4.0 была масса косяков в проставлении складских аналитик у заказов на перемещений. В результате могло получиться так, что товар списывался по одним аналитикам, а зачислялся по другим. Само собой АХ дальше-то работала верно, но закрытие склада вешалось из-за того, что переносы, перемещения, спецификации, закупки и продажи сопоставлялись ээээ ну в общем не так, как это ожидалось пользователями.