Цитата:
Сообщение от
fed
Это ты про алгоритм версий 2.1-2.5 рассказываешь. Там действительно обороты в разрезе периодов в таблицах балансов хранились. А с версии 3.0 - в разрезе дней храняться.
опаньки. спасибо.
значит теперь нельзя управлять размером LedgerBalances...
Цитата:
Сообщение от
fed
Соответственно функция ledgerBalance_sumCurrent() считает просто тупо суммируя ledgerBalancesDimTrans. Никакой схемы Балансы+обороты по ledgerTrans там с 2003 года не используется.
ledgerBalance_sumCurrent() - абстрактный класс.
см. LedgerBalanceSum_CurrentMST.buildQuery()
(но! см. LedgerBalanceCur_Current.buildQuery, который работает по LedgerTrans)
Цитата:
Сообщение от
fed
А учитывая что размеры ledgerTrans и ledgerBalancesDimTrans сопоставимы обычно (ну то есть - конечно балансы поменьше, но поменьше раза в два, может в три), то выигрыш от использования информации балансов невелик.
Не... вот здесь категорически не согласен.
они сопоставимы только если в финансовые аналитики заталкивают контрагентов, номенклатуру, партии. Т.е. справочную информацию, которая должна быть в других модулях и в соответствующих *Trans-таблицах.
Да, если из Аксапты делать 1С с ее субконтами, то будут почти такие же тормоза, как и у субконто.
И снова хочу обратить внимание на распределение таблиц в случае, который я считаю типичным
Производительность
Цитата:
Сообщение от
fed
После того как в DAX2009 они вообще стали балансы складывать тупым суммированием оборотов по счету+аналитика внутри ваучера (то есть - даже не по схеме 20 записей в день по счет+аналитика), то выигрышь, скорее всего, станет еще более призрачным.
Я согласен с тем, что чем дальше, тем меньше остается от первоначальных замыслов. Все как-то размывается... Вводятся фичи, которые драматически ухудшают производительность. Например,
Как глобально отключить автоопределение ширины столбца = autoSizeColumns(false) ?