Цитата:
Сообщение от
fed
Во вторых - по моим наблюдениям, размер ledgerBalancesDimTrans (по крайней мере по числу записей) составляет где-то порядка 40-60% от размера самого ledgerTrans. Так что экономия от использования ledgerBalances достаточно небольшая.
не.
1.
это ж принципиальная вещь, о которой давным-давно говорится:
число комбинаций финансовых аналитик (!) должно быть относительно невелико.
иначе LedgerBalancesDim* раздувается и Аксапта начинает работать медленно.
Это значит, попытки затолкать в фин.аналитики всякие номенклатуры, контрагентов (а тем более, ГТД, партии) обречены на тормоза.
2.
В Аксапте 3.0, 4.0 есть галочка "Не учитывать коды аналитики"
которая не переносит значения LedgerBalancesDim на следующий фин.год.
LedgerBalances (сальдо по счетам) - переносится, а аналитика - не переносится.
Что сильно уменьшает размер LedgerBalancesDim
В Аксапте 2009 перенесли эту галочку в периодическую операцию "Открывающие проводки".
Другое дело, что поведение пока все еще тупое.
В принципе, надо бы иметь возможность управлять поведением переноса аналитик по каждому счету и по каждой аналитике. Что мы обычно и модифицируем.
В общем, когда-то люди об этом думали. Но хотелось бы большего.
Цитата:
Сообщение от
fed
Учитывая что в ledgerBalances отсутствует некоторая информация которая бывает нужна для запросов (тот же код валюты к примеру или сумма в валюте), то проще с самого начала не заморачиваться и написать запросы по ledgerTrans.
Не так малешко. По-моему.
(Конечно можно подходить по разному к этому вопросу: пессимист скажет, что не подумали, оптимист придумает оправдание
)
По-моему, тут важен баланс между скоростью и объемом.
Ведь не ставиться цель избавиться от запросов "от начала времен".
Цель по-моему найти оптимальную скорость.
Если бы я реализовывал эту фичу, то я бы подумал так:
С одной стороны:
= все операции идут в основной валюте. Поэтому запрос к LedgerTrans в основной валюте неизбежно приведет к выборке ВСЕХ ledgerTrans за период
= операций в валюте (скорее всего) будет не так много. Поэтому запрос к LedgerTrans по валюте будет достаточно селективным (выборка будет меньше, чем "все записи за период").
С другой стороны:
= чем больше размер LedgerBalances*, тем меньше смысла в этих таблицах.
Поэтому, возможно, я бы остановился на решении, что сальдо в основной валюте рассчитывается на основании LedgerBalances*, а остальные сальдо - прямыми запросами.
Цитата:
Сообщение от
fed
Ну проиграем 20-30 процентов в производительности запроса, да и хрен с ним по большому счету. Все-таки в Аксапте данные ГК не принято использовать ни для каких других целей кроме ограниченного круга запросов, нет смысла особо париться по поводу падения производительности на 20-30 процентов в отчетах, которые строит один человек один раз в месяц...
20-30? При выборке
из десятков-милионнов записей?
А самое главное - при выборке "от начала времен" можно забыть о сегментировании данных в SQL. Поскольку эффект будет не сильно заметным (разве что за счет отдельной обработки индексов в разных сегментах).