fed: Ledger Balance Data in DAX

[fed]

Цитата:

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

Не. Тут ты не прав.

Во-первых, в LedgerBalances хранятся начальные остатки на начало финансового года.
Следовательно вместо выборки из LedgerTrans от начала времен
они делают выборку из LedgerBalances от начала фин.года плюс выборка LedgerTrans от начала фин.периода до даты. Что существенно меньше.

Хочу заметить, что если мы заключительной ведомостью пользовались, то у нас по ledgerTrans тоже можно считать не с начала времен, а с начала финансового года. Во вторых - по моим наблюдениям, размер ledgerBalancesDimTrans (по крайней мере по числу записей) составляет где-то порядка 40-60% от размера самого ledgerTrans. Так что экономия от использования ledgerBalances достаточно небольшая. Учитывая что в ledgerBalances отсутствует некоторая информация которая бывает нужна для запросов (тот же код валюты к примеру или сумма в валюте), то проще с самого начала не заморачиваться и написать запросы по ledgerTrans. Ну проиграем 20-30 процентов в производительности запроса, да и хрен с ним по большому счету. Все-таки в Аксапте данные ГК не принято использовать ни для каких других целей кроме ограниченного круга запросов, нет смысла особо париться по поводу падения производительности на 20-30 процентов в отчетах, которые строит один человек один раз в месяц...

[mazzy]

Цитата:

Сообщение от 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. Поскольку эффект будет не сильно заметным (разве что за счет отдельной обработки индексов в разных сегментах).

[glibs]

Цитата:

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

...
по моим наблюдениям, размер ledgerBalancesDimTrans (по крайней мере по числу записей) составляет где-то порядка 40-60% от размера самого ledgerTrans.
...

Готов подтвердить.

Я тоже наблюдал такой эффект. Аналитики использовались почти адекватно. Архитектурно одна действительно дублировала аналитический справочник. Но на практике она не давала много записей, т.к. модуль использовался мало.

Проблема была в активном использовании нескольких сот статей затрат (и доходов) в комбинации с несколькими десятками ЦФО да и еще в почти с десятке компаний в одной базе. Широковат был еще справочник ДДС.

Однако в плане счетов проводилась очень жесткая оптимизация, чтобы на счета не писались лишние аналитики. Например, на 51-х счетах разрешался только ДДС, на 60-х и 62-х ЦФО, и т.п., а на большинстве счетов все или почти все аналитики вообще безжалостно терлись (например, счет ввода начальных сальдо, счета курсовой разницы), чтобы не было лишних ненужных для анализа сальдо на счетах по комбинациям аналитик.

Но...

Автоматизирован был финансовый учет (учет расходов, дебиторка и кредиторка, та же реформация баланса, движение ДС). Логистики и складских проводок не было. Количество проводок в ГК получалось... не маленьким, но и не очень грандиозным.

Если бы использовался логистический функционал без переноса аналитических справочников в финансовые аналитики (на что так нападает Маззи), то с почти одинаковыми проводуками по заказам на продажу и покупку, а также складскими проводками соотношение между количеством записей в таблицах итогов и транзакций отличалось бы в разы. Ткнулся вот в старую статистику по одному из логистических внедрений — более 4 раз. Другая — почти 10.

Так что лучше не выдергивать фразы из контекста, а приводить более подробное описание условий, на которых получаются те или иные показатели.

Длина записи в LedgerTrans по статистике у меня сопоставима с длиной записи в таблице LedgerBalancesDimTrans. Но я предполагаю, что просто не был настроен текст проводки. Под индексы в LedgerBalancesDimTrans занято в 5 раз меньше места в пересчете на одну запись таблицы. LedgerBalancesDimTrans можно пытаться дополнительно индексировать для ускорения определенных выборок.

[glibs]

Цитата:

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

...
проще с самого начала не заморачиваться и написать запросы по ledgerTrans. Ну проиграем 20-30 процентов в производительности запроса, да и хрен с ним по большому счету. Все-таки в Аксапте данные ГК не принято использовать ни для каких других целей кроме ограниченного круга запросов, нет смысла особо париться по поводу падения производительности на 20-30 процентов в отчетах, которые строит один человек один раз в месяц
...

Да кто придумал этого одного человека в месяц???

Сколько будет строиться финансовый (не ГФО, а международный) отчет с двадцатью колонками (желательно с данными из нескольких периодов или с разбивкой по какой-то финансовой аналитике) и несколькими сотнями строк (с детализацией по аналитикам по двум уровням, например), если его пустить по проводкам ГК?

В ГФО (разумеется после его модернизации, когда он начал отправлять на сервер БД запросы с агрегированием) такие отчеты строятся часами на базе с промышленными данными даже в пределах календарного года. В финотчетах минуты.

Обратите внимание как индексированы проводки ГК и как индексирована та же LedgerBalancesDimTrans.

Блин. Не нужно выкидывать сальдовые таблицы! Не хотите — не пользуйтесь. Флаг вам в руки. Не портите жизнь другим. А то в Микрософте любят что-то, чем уже пользуются, разрушить и построить что-то новое в стиле: "Нате вам здрасьте". Не поломать старый удобный инструмент ради нового, а просто создать еще один чтобы были опции по принципу "на вкус и цвет товарищей нет" им что-то там не позволяет. Подозреваю что "эго" очередной команды, дорвавшейся до руля. Не дай бог к вам прислушаются.