Я бы еще добавил, что при использовании inventSumDate() возникает некоторый накладняк (и довольно заметный) в связи с тем что на SQL Server отсылается много мелких запросов, каждый из которых отдельно разбирается и исполняется. Кроме того - по каждому из этих запросов случается трафик между SQL и AOS. В то же время если у тебя тупой запрос по inventTrans, то у тебя на сервер уходит один могучий запрос, потом сервер думает и сразу присылает данные на клиента крупным оптом, так сказать. Так что если у тебя сервер БД мощный, то тупое чтение с начала времен может запросто выиграть у хитроумных подходов со сбором данных из inventSum/inventTrans/inventSettlement/InventTransPosting. В сущности - 6 миллионов записей - это ведь порядка полутора гигабайт данных. Даже если у нас в кэше ничего нету - сколько времени с приличного дискового массива будут данные читаться ? Около минуты наверное... А если у тебя дисковые подсистемы на разных каналах висят и данные по этим каналам размазаны, то за счет параллельного чтения запросто можно и в секунд 15-20 уложиться...
К слову сказать - если в системе номера партий используются (а это правильное и вполне поддерживаемое создателями системы ее использование), то размерность inventSum и inventTrans может быть вполне сопоставимой...
|