AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 26.09.2010, 15:05   #1  
Blog bot is offline
Blog bot
Участник
 
25,459 / 846 (79) +++++++
Регистрация: 28.10.2006
fed: Ledger Balance Data in DAX
Источник: http://fedotenko.info/?p=167
==============

I remembering the first time when our team was developing a solution which was supposed to quickly calculate the GL balance for specific GL Account/Dimension combination. It was 2001 and we were developing the cost allocation functionality.

We just started to work with Axapta 2.1, so – our first approach was simply to calculate a GL Balance by summing up LedgerTrans table from the beginning of times . Soon, after we went live, we realized that the brute force approach is not always the most successful way of doing things in Axapta.

Luckily, we found the ledgerBalance and LedgerBalanceDim tables. First table contained the summed up GL turnover per GL Account+Period; Second table contained the summed up GL turnover per GL Account+GL Dimensions+Period. After we started to use these two tables for calculation GL balance from these two tables, we saw dramatic improvement in performance, since 200-300 of ledgerTrans records was packed into one record of these balance tables. (We had around 10-15 postings per GL Account daily and our GL period was a month).

Little bit later (like in the Fall 2001), we found out that these two tables is a more like part of problem than part of solution. Every time when you design some table which holds summed-up data for quick retrieval, one should remember that update of the data in the table will hold the lock on the table’s record until end of the transaction. So, If Axapta was implemented in the company, which did not have very detailed GL account sheet  (say only 3-4 GL accounts was used to hold the customer’s payment balance), posting of the multi-line payment journal could prevent everyone else from posting ANY other customer-related document for 5-10 minutes. Somewhere in the beginning of transaction, system was updating the balance data and then this data was locked until the end of transaction. In connection with mutual locking during inventory update, which I discussed in my article “History of Inventory Locking”, this had a rather catastrophic consequences for the system’s stability and performance. Couple of carefully planted orders/journals with the same GL accounts and inventory items, could make system unusable for a whole business day . The only remedy for this was the usage of batch servers for posting of nearly all documents, because batch server was naturally preventing any competition for resources by converting several potentially parallel processes into one sequential queue of processes. This approach could be a solution for accountancy-centric implementations, but any real time process, like WMS  just could not be fixed this way. That’s why I never believed into any of success stories telling about WMS implementation in Axapta made BEFORE release of Axapta 3.0.

The situation was relieved in Axapta 3.0.  These two tables was replaced with LedgerBalanceTrans/ledgerBalanceDimTrans tables. To prevent lock chains and deadlock during an update of balance data, developers of Axapta introduced two additional fields to these new tables: the transaction date and the funny named field ‘LedgerBalancesVariant’. First thing, we realized that now balance data is stored on per-date basis, but not per-period. Initially, the meaning of this Variant field was not clear for me. Soon, I found out that actually, system keeps up to 20 (TWENTY) GL balance records for the same date and same account/dimension combination. During update, system was RANDOMLY selecting a number from 1 to 20 and then updating/inserting balance record with arbitrary Variant number. (Actually – It was not complete random number. It was calculated as Variant= (SessionId mod 20), so update of the same account/dimension combinations from the same session went to the same balance record. If they were using true random() value, update from the same session and the same DB transaction would be scattered across several records even it was the only transaction for the combination in the day.) Thus, chances for long locks was greatly decreased. Even if GL account sheet is too coarse grained, probability for two users to update the same record at the same time now was like only 5%. When I first studied this concept, I had an idea that maybe after 300-400 concurent users, I would increase the number of these ‘variants’ to 30-40, but actually this idea proved to be wrong, since I never saw any serious lock contentions on ledger balance data since release of version 3.0. Of course, if someone were to monitor process locking in MS SQL, he/she would see occasional waiting locks on ledgerBalanceTrans/ledgerBalanceDimTrans from time to time, but generally – balance data had ceased to be the main bottleneck of system’s performance.

From the other side – this solution actually traded update performance for for query performance. After balance data have been scattered across 20 variants and stored on the per-date basis, size of ledger balance table became comparable to the size of the ledger transactions table itself. Typically, size of LedgerBalanceDimTrans table became to be around 50-70% of ledgerTrans table. Since then, usage of ledgerBalanceDimTrans instead of ledgerTrans for reporting purposes became unnecessary complication, since query time for the both cases was comparable, but ledger balance data sometimes lacked necessary details important for some particular reports. Of course, in may cases usage of ledgerBalanceDimTrans was little bit more convenient then direct usage of ledgerTrans data, since one record of the balance table holds both debit and credit turnover, while fetching the corresponding data from ledgerTrans with ‘group by crediting’ would give us debit and credit turnovers in different records.

When I first saw ledger balance tables in Dynamics AX 2009 I was very surprised to see that field Variant had gone. First of all I had not expected any changes in these area since it had became non-problematic since 2003. Second – I saw no way for this mechanism to exists without Variant field.

Actually, it turns out that designers of financial subsystem in Axapta realized that actual results from usage of this Variant algorithm was satisfactory, but not perfect. From one side, we lost almost all of our DB space/query time savings from ledgerBalance* usage, from the other side – we still can have a lock conflicts on ledger balance data updates. (Though less frequent). So the designers decided to store ONE balance record per ONE ledger voucher. In the worst case (if we have post mostly one-line documents) we will have the number of ledgerBalance* records equal to the number of ledgerTrans records. In the realistic case (we post at least 50-70% of multi-line documents) we will have the same number of records as in Variant-mechanism. Since now these balance data is not a query performance increase mechanism anyway since 2003, actual size of ledgerBalances* tables does not matter; It enough for them to not outgrow ledgerTrans itself. From the other side, since EVERY ledger voucher now has it own balance record, there is no chance of lock conflicts at all.

One interesting point which is worth to mention about the new mechanism is the way how these balance updates are being made now:
  1. All updated balances made in one ledgerVoucher is kept in RecordSortedList (thus – in memory) somewhere in LedgerBalancesList/LedgerBalancesPostingList class.
  2. As soon as posting of ledgerVocher has finished, or the list became to large to hold in memory it is being flushed to quasi-temporary table LedgerBalancesTransDelta.
  3. In the end of ledgerVoucher, system opens separate additional database connection and use this separate connection to execute insert_recordset statement which insert new balance records by summing up ledgerBalancesTransDelta. This update use optimistic locking mechanism (with transaction retry), but since this is separate transaction with a very little of actual database update, it can be rolledback and retried with much overhead. (And this is exact reason to use separate transaction for this update! If we were to use the main database transaction, in case of lock conflict, this would cause a great overhead (Imagine 20000 lines FA depreciation journal, which was rolled back and posted again because of balance data lock conflicts).
  4. Finally, the records belonging to current session are being deleted from ledgerBalancesTransDelta. (That is why this table called quasi temporary).
Although, as I said, I have never seen any actual implementations of Dynamics AX 3-4 which really suffered from ledger balance data related bottlenecks, It might be that these problems would arise in 3000-4000 user implementation. (Never have seen personally implementations with more then 700-800 users). Overall, the whole history of changing approach to balance data in DAX looks like a good example of software design and engineering.



Источник: http://fedotenko.info/?p=167
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
Старый 26.09.2010, 16:29   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
как всегда, отлично.
на русском бы, а?
__________________
полезное на axForum, github, vk, coub.
Старый 26.09.2010, 17:15   #3  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
885 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Возможно я тормоз и не понимаю "модных" архитектурных тенденций в архитектуре БД, но тем не менее - чем же, для получения баланса на дату, вариант архитектуры агрегированных оборотов по субсчетам/ субсчетам и аналитикам (т.е LedgerBalancesTrans и LedgerBalancesDimTrans), требующий ежеоперационного обновления и решения проблем блокировок из-за этих частых операций, настолько превосходит прочие варианты получения баланса ГК, например "ближайший остаток на дату + операции да даты баланса", не требующий ежеоперационного обновления и не порождающего такого кол-ва блокировок ?
__________________
Мы летаем, кружимся, нагоняем ужасы ...
Старый 26.09.2010, 17:40   #4  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
Возможно я тормоз и не понимаю "модных" архитектурных тенденций в архитектуре БД, но тем не менее - чем же, для получения баланса на дату, вариант архитектуры агрегированных оборотов по субсчетам/ субсчетам и аналитикам (т.е LedgerBalancesTrans и LedgerBalancesDimTrans), требующий ежеоперационного обновления и решения проблем блокировок из-за этих частых операций, настолько превосходит прочие варианты получения баланса ГК, например "ближайший остаток на дату + операции да даты баланса", не требующий ежеоперационного обновления и не порождающего такого кол-ва блокировок ?
Только для того чтобы можно было показывать балансы по счету на любую дату сразу с дебетом и кредитом . Вообще-то по моему все это - архитектурный пережиток времен медленных серверов БД...
Старый 26.09.2010, 20:02   #5  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
885 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Цитата:
Сообщение от fed Посмотреть сообщение
Только для того чтобы можно было показывать балансы по счету на любую дату сразу с дебетом и кредитом .
Как правило, суммарные обороты по дебету и кредиту гораздо чаще интересуют конечного потребителя за какой-то определенный и конечный промежуток времени, кратный неким отчетным периодам, нежели суммы многолетних движений "от начала времен до какой-то даты ", которые предлагает используемая архитектура. К тому же эта архитектура для получения баланса по счету ГК с течением времени предполагает монотонное нарастание количества анализируемых записей, в отличие от второго способа, в котором кол-во выбираемых записей - всегда некая константа плюс/минус некий процент.
Цитата:
Сообщение от fed Посмотреть сообщение
Вообще-то по моему все это - архитектурный пережиток времен медленных серверов БД...
Т.е. все эти варианты хранения промежуточных результатов для ускорения расчета остатков - от бедности ?
__________________
Мы летаем, кружимся, нагоняем ужасы ...
За это сообщение автора поблагодарили: Bober (2).
Старый 26.09.2010, 21:42   #6  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
Как правило, суммарные обороты по дебету и кредиту гораздо чаще интересуют конечного потребителя за какой-то определенный и конечный промежуток времени, кратный неким отчетным периодам, нежели суммы многолетних движений "от начала времен до какой-то даты ", которые предлагает используемая архитектура. К тому же эта архитектура для получения баланса по счету ГК с течением времени предполагает монотонное нарастание количества анализируемых записей, в отличие от второго способа, в котором кол-во выбираемых записей - всегда некая константа плюс/минус некий процент.

Т.е. все эти варианты хранения промежуточных результатов для ускорения расчета остатков - от бедности ?
Вообще-то используемая архитектура, в запаном учете, позволяет, для подсчета сальдо и для подсчета оборотов всегда плясать ТОЛЬКО от начала финансового года. Просто у них в конце одного финансового года все сальдо списывают на некий счет, а потом в начале следующего финансового года все эти сальдо восстанавливают с того же самого счета (а может быть и с другого). Так что в западном учете сальдо равно оборотам с начала финансового года, считать с начала времен - необязательно. Так что это как раз и есть схема "Остаток+обороты".Но все равно - размер ledgerBalances и ledgerTrans а период сопоставим не зависимо то того, как мы считаем - с начала времен или с начала финансового года.
Кстати - я слышал что и в некоторых российских внедрениях используют заключительную ведомость в конце года для списания/приходования остатков. Правда, это не очень вяжется с русскими ПБУ...
А все это до сих пор используют потому что:
1. Во первых так сложилось. Когда авторы догадались о том что с блокировками все нехорошо, вероятно уже поздно было выкинуть эти таблицы.
2. Во вторых - эта архитектура позволяет собрать и дебетовые и кредитовые обороты в одной строке. Не так чтобы это великим достижением было, но иногда приятно.
3. Архитектура позволяет сэкономить немножко на времени доступа к данным. Хотя на мой взгляд, подобная экономия уже не стоит накладняка.

Последний раз редактировалось fed; 26.09.2010 в 21:45.
Старый 26.09.2010, 22:15   #7  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от fed Посмотреть сообщение
Кстати - я слышал что и в некоторых российских внедрениях используют заключительную ведомость в конце года для списания/приходования остатков. Правда, это не очень вяжется с русскими ПБУ...
Почему это не вяжется? В Российском учете есть понятие "реформация баланса", это именно то, что требуется. К тому же, существуют несколько ПБУ, описывающих работу после закрытия периода (одно из них обновлено не так давно) - все они требуют корректировок "вне времени", то есть именно в заключительной ведомости.
Поэтому вариант подсчета с начала финансового года вполне рабочий и ничем не противоречит ПБУ.
Старый 26.09.2010, 22:34   #8  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
прочие варианты получения баланса ГК, например "ближайший остаток на дату + операции да даты баланса",
Если не секрет, то что такое:
Цитата:
ближайший остаток на дату
На какую дату?
Старый 26.09.2010, 23:56   #9  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Почему это не вяжется? В Российском учете есть понятие "реформация баланса", это именно то, что требуется. К тому же, существуют несколько ПБУ, описывающих работу после закрытия периода (одно из них обновлено не так давно) - все они требуют корректировок "вне времени", то есть именно в заключительной ведомости.
Поэтому вариант подсчета с начала финансового года вполне рабочий и ничем не противоречит ПБУ.
А поподробнее можешь рассказать? Мне просто казалось что реформацией баланса называют процедуру закрытия в конце учетного периода сальдо на 90.09/91.09/99 на счета нераспределенной прибыли (в общем - куда-то на 8x, подзабыл я уже русский план счетов). При этом счета прибылей и убытков закрываются конечно, но во первых в обычном учетном периоде, во вторых -счета активов и пассивов так и переходят на новый учетный период. А в западном учете, как мне казалось, в конце периода закрывают все счета, а потом в новом году их с ноля открывают. То есть - фактически иммитация бумажного учетного журнала, в котором последняя запись старого финансового года закрывает все счета на так называемый счет баланса, а первая запись нового года - открывает все счета со счета баланса...
Старый 27.09.2010, 02:52   #10  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
...чем же ... вариант архитектуры агрегированных оборотов ... настолько превосходит прочие варианты получения баланса ГК, например "ближайший остаток на дату + операции да даты баланса"...
я не очень понял смысла второго варианта.
но я точно знаю чем отличается от варианта "суммирование от начала времен" - резко уменьшается выборка из базы.

LedgerBalanceTrans/ledgerBalanceDimTrans позволяют не дергать записи из LedgerTrans от начала времен.
Производительность
Стандартные методы получения сальдо/оборотов берут записи из LedgerTrans только в ближайшем финансовом периоде (который может быть уменьшен администратором с месяца до дня).

просто преступно суммировать от начала времен записи в этой таблице потому что:
  • таблица LedgerTrans - входит в Top10 по объему на большинстве внедрений. А заставлять SQL делать одни и те же громадные выборки - не комильфо.
  • у таблицы LedgerTrans до сих пор переопределен метод PostLoad
__________________
полезное на axForum, github, vk, coub.
Старый 27.09.2010, 03:04   #11  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от fed Посмотреть сообщение
Так что в западном учете сальдо равно оборотам с начала финансового года, считать с начала времен - необязательно. Так что это как раз и есть схема "Остаток+обороты".Но все равно - размер ledgerBalances и ledgerTrans а период сопоставим не зависимо то того, как мы считаем - с начала времен или с начала финансового года.
Не. Тут ты не прав.

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

Другими словами:
1. от начала времен: LedgerTrans[<DateTo]
2. с оборотами: LedgerBalances[>=StartFinYear, <StartFinPeriod] + LedgerTrans[>=StartFinPeriod, <DateTo]

пример Производительностьтабличном виде)
Обрати внимание, что LedgerTrans - самая большая таблица.
А LedgerBalances не входит даже в первую двадцатку.
И это типичная ситуация.

Кроме того, даже выборка из LedgerBalances ведется не по всему объему, а только по последнему финансовому году. Что здорово сказывается, если база содержит данные за 5-8-10-и-более лет.
Не говоря уже об уменьшении выборки LedgerTrans

это только уменьшение выборки.
а если вспомнить про возможность сегментирование данных (старые скидывать в отдельную файловую группу).
а если еще вспомнить про метод PostLoad...
__________________
полезное на axForum, github, vk, coub.
Старый 27.09.2010, 03:10   #12  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от fed Посмотреть сообщение
Правда, это не очень вяжется с русскими ПБУ...
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Почему это не вяжется?
... несколько ПБУ... требуют корректировок "вне времени", то есть именно в заключительной ведомости.
Да... хорошо бы иметь проводки по реформации "вне времени", чтобы иметь возможность получать отчеты с учетом по реформации и без них.

И такую возможность вполне можно сделать, создавая закрывающие периоды не только в конце года, но и в конце каждого месяца.

А вот что не соответствует... Закрытие по российским правилам требует многоуровневого закрытия 26-23-20-90-88. А в буржуйских все счета прибылей и убытков сразу закрываются на 88. Поэтому заключительная ведомость не очень подходит в российских условиях. Приходится либо допиливать заключительную ведомость, либо разрешать указывать в журналах тип периода (обычный, закрывающий).
__________________
полезное на axForum, github, vk, coub.
Старый 27.09.2010, 06:32   #13  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
885 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Если не секрет, то что такое:
Некий аналог InventSum, т.е. хранение промежуточных входящих остатков по счету/аналитике ГК на определенные даты (как правило на начало какого-либо отчетного периода с определенным квантованием, например на начало года, квартала или месяца) с расчетом баланса на определенную дату по алгоритму "ближайшее по дате сальдо до даты баланса + операции с даты найденного сальдо до даты баланса". В отличии от используемого алгоритма несколько более затратен в плане вычислений, но не требует ежеоперационного обновления каких-то агрегированных оборотов, а только периодических процедур закрытия периода с расчетом сальдо, кои не блещут такой любовью к созданию блокировок.
Стандартный функционал AX по конечному результату нечто подобное и позволяет делать через операции в закрывающем/открывающем периодах, но в случае отказа от их использования - все начинает сводиться к банальному суммированию агрегированных оборотов с начала времен.
__________________
Мы летаем, кружимся, нагоняем ужасы ...
Старый 27.09.2010, 09:41   #14  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от mazzy Посмотреть сообщение
Не. Тут ты не прав.

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

Последний раз редактировалось fed; 27.09.2010 в 09:48.
Старый 27.09.2010, 09:50   #15  
Bober is offline
Bober
Участник
 
311 / 104 (4) +++++
Регистрация: 29.05.2007
Цитата:
Сообщение от fed Посмотреть сообщение
Когда авторы догадались о том что с блокировками все нехорошо
Это п. Столько лет уже Аксапте. А всё одни и те же грабли. Когда в разрабокту Микрософт перестанут брать дураков ?
Старый 27.09.2010, 09:59   #16  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от mazzy Посмотреть сообщение
Другими словами:
1. от начала времен: LedgerTrans[<DateTo]
2. с оборотами: LedgerBalances[>=StartFinYear, <StartFinPeriod] + LedgerTrans[>=StartFinPeriod, <DateTo]
Это ты про алгоритм версий 2.1-2.5 рассказываешь. Там действительно обороты в разрезе периодов в таблицах балансов хранились. А с версии 3.0 - в разрезе дней храняться. Соответственно функция ledgerBalance_sumCurrent() считает просто тупо суммируя ledgerBalancesDimTrans. Никакой схемы Балансы+обороты по ledgerTrans там с 2003 года не используется.
А учитывая что размеры ledgerTrans и ledgerBalancesDimTrans сопоставимы обычно (ну то есть - конечно балансы поменьше, но поменьше раза в два, может в три), то выигрыш от использования информации балансов невелик.
После того как в DAX2009 они вообще стали балансы складывать тупым суммированием оборотов по счету+аналитика внутри ваучера (то есть - даже не по схеме 20 записей в день по счет+аналитика), то выигрышь, скорее всего, станет еще более призрачным.
За это сообщение автора поблагодарили: TasmanianDevil (3).
Старый 27.09.2010, 10:06   #17  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Bober Посмотреть сообщение
Это п. Столько лет уже Аксапте. А всё одни и те же грабли. Когда в разрабокту Микрософт перестанут брать дураков ?
Справедливости сказать - схема-то еще в Дамгаарде была разработана...
Равно как и способ преодоления последствий с помощью вариантов...

А по поводу Микрософта - я лично считаю что идеальным вариантом (по крайней мере для коммюнити) была бы продажа микрософтом прав на Аксапту (равно как и другие ERP-продукты) в какие-то фирмы которые бы хоть какую-то внедренческую практику имели бы, а не только программили бы чего-то из соображений архитектурной стройности...
Старый 27.09.2010, 11:08   #18  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от fed Посмотреть сообщение
Во вторых - по моим наблюдениям, размер ledgerBalancesDimTrans (по крайней мере по числу записей) составляет где-то порядка 40-60% от размера самого ledgerTrans. Так что экономия от использования ledgerBalances достаточно небольшая.
не.
1.
это ж принципиальная вещь, о которой давным-давно говорится:
число комбинаций финансовых аналитик (!) должно быть относительно невелико.
иначе LedgerBalancesDim* раздувается и Аксапта начинает работать медленно.

Это значит, попытки затолкать в фин.аналитики всякие номенклатуры, контрагентов (а тем более, ГТД, партии) обречены на тормоза.

2.
В Аксапте 3.0, 4.0 есть галочка "Не учитывать коды аналитики"
которая не переносит значения LedgerBalancesDim на следующий фин.год.
LedgerBalances (сальдо по счетам) - переносится, а аналитика - не переносится.
Что сильно уменьшает размер LedgerBalancesDim
Нажмите на изображение для увеличения
Название: ax4.PNG
Просмотров: 485
Размер:	34.7 Кб
ID:	6184

В Аксапте 2009 перенесли эту галочку в периодическую операцию "Открывающие проводки".
Нажмите на изображение для увеличения
Название: ax2009.PNG
Просмотров: 401
Размер:	45.3 Кб
ID:	6185

Другое дело, что поведение пока все еще тупое.
В принципе, надо бы иметь возможность управлять поведением переноса аналитик по каждому счету и по каждой аналитике. Что мы обычно и модифицируем.


В общем, когда-то люди об этом думали. Но хотелось бы большего.


Цитата:
Сообщение от fed Посмотреть сообщение
Учитывая что в ledgerBalances отсутствует некоторая информация которая бывает нужна для запросов (тот же код валюты к примеру или сумма в валюте), то проще с самого начала не заморачиваться и написать запросы по ledgerTrans.
Не так малешко. По-моему.
(Конечно можно подходить по разному к этому вопросу: пессимист скажет, что не подумали, оптимист придумает оправдание )

По-моему, тут важен баланс между скоростью и объемом.
Ведь не ставиться цель избавиться от запросов "от начала времен".
Цель по-моему найти оптимальную скорость.

Если бы я реализовывал эту фичу, то я бы подумал так:
С одной стороны:
= все операции идут в основной валюте. Поэтому запрос к LedgerTrans в основной валюте неизбежно приведет к выборке ВСЕХ ledgerTrans за период
= операций в валюте (скорее всего) будет не так много. Поэтому запрос к LedgerTrans по валюте будет достаточно селективным (выборка будет меньше, чем "все записи за период").

С другой стороны:
= чем больше размер LedgerBalances*, тем меньше смысла в этих таблицах.

Поэтому, возможно, я бы остановился на решении, что сальдо в основной валюте рассчитывается на основании LedgerBalances*, а остальные сальдо - прямыми запросами.

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

А самое главное - при выборке "от начала времен" можно забыть о сегментировании данных в SQL. Поскольку эффект будет не сильно заметным (разве что за счет отдельной обработки индексов в разных сегментах).
__________________
полезное на axForum, github, vk, coub.
Старый 27.09.2010, 11:22   #19  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от 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) ?
__________________
полезное на axForum, github, vk, coub.
Старый 27.09.2010, 11:26   #20  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от fed Посмотреть сообщение
А по поводу Микрософта - я лично считаю что идеальным вариантом (по крайней мере для коммюнити) была бы продажа микрософтом прав на Аксапту (равно как и другие ERP-продукты) в какие-то фирмы которые бы хоть какую-то внедренческую практику имели бы, а не только программили бы чего-то из соображений архитектурной стройности...
Ой. Тогда будет лучше 1Сом заниматься.

Лично я считаю, что идеальным вариантом было бы: единый инструмент разработки как для самих разработчиков в MS, так и для клиентов.

Если разработчики в MS привыкли работать в VS, то пусть VS и будет этим единым инструментом. И юнит-тестирование, и работа с базой, и отчеты, и внешние приложения должны редактироваться в одном инструменте, по одинаковым правилам.

А то получается фигня какая-то, типа Райкинского "К гульфику претензии есть?"
Выборка данных через AOS vs SQL Server
__________________
полезное на axForum, github, vk, coub.
Теги
ledgerbalance, ledgerbalancesdimtrans, ledgerbalancestrans, главная книга, итоги, сальдо, crm2011

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
fed: History of inventory locking in DAX Blog bot DAX Blogs 0 28.09.2009 16:05
Microsoft DAX Dev Center Headlines: New Ledger Posting White Paper Released Blog bot DAX Blogs 0 23.11.2008 12:05
axStart: Change data on a data source on a Form Blog bot DAX Blogs 0 04.09.2008 15:05
Microsoft Dynamics CRM Team Blog: Data Migration Manager Tips and Tricks Blog bot Dynamics CRM: Blogs 0 02.09.2008 22:05
Пустые названия системных таблиц в report data range (DAX 4.0) Qaz Qwerty DAX: Функционал 3 06.08.2008 00:05
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:24.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.