![]() |
#20 |
Участник
|
Цитата:
Цитата:
Сообщение от sukhanchik
![]() InventTrans
В свое время (АХ 4.0) у меня была задача поиска "закольцованных" движений. Соответственно, чтобы понять "кольцо" - нужно для каждой записи (каждого типа движения) применить свой алгоритм обработки. На выходе может получиться неопределенно много записей и тривиальный фильтр не подходит, соответственно ссылку на RecId найденных записей было удобно записывать в RecordReference_RU, а затем открывать стандартную форму InventTrans, отфильтрованную по отобранным движениям. или ты лот возврата имеешь в виду. а как у него кольцо может образоваться? Цитата:
в результате получить отдельно дебетовые и кредитовые обороты в одном запросе по одной таблице становится проблематично. хотя если можно использовать больше одного датасорса по одной таблице... ))) Цитата:
Сообщение от S.Kuskov
![]() Более общая формулировка задачи:
Как (с минимальными накладными затратами) результат (выход) одного алгоритма подать на вход следующего, так что бы алгоритмы не зависили от тонкостей реализации друг друга. Общего рецепта по-видимому нет. Когда-то будут более выгодны временные таблицы, когда-то квазивременные Один класс инкапсюлирует одно, другой класс - другое. они могут использовать друг-друга. тут вопрос оптимальности и нагрузки на базу. очень многие люди считают, что один монстр-запрос будет работать оптимальнее. поэтому не разбивают на классы. но надо оптимизировать не запрос. а систему в целом. которая работает в многопользовательском режиме. если рассматривать систему в целом, то монстр-запросы как правило очень плохо влияют на среднюю отзывчивость сервера и среднюю производительность. в среднем лучше на SQL подавать несложные и однотипные запросы. даже если при этом получаются не самые минимальные resultSet'ы. |
|
Теги |
distinct, recordrefrencelist_ru, recordsortedlist, view |
|
|