fed: Ledger Balance Data in DAX

[fed]

Цитата:

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

блин, ребяты, да вы что!!!?


petr, смотрите внимательно на свойство FieldUpdate у полей, которые отвечают за суммы.
там не только вставка.

Кстати - а зачем тогда авторы добавили recId в конец вроде бы уникального от природы индекса по значимым полям ?
У меня попытка удалить из индекса recId с сохранением уникальности - жостко обломалась...

[fed]

Я кстати сначала (когда разбирался) решил что они сделают группировку не по ваучерам, а по транзакциям. Типа записали все обновления в ходе транзации в ledgerBalanceTransDelta, а потом в конце вызвали обработчик и все в одну запись в балансах столкнули. Но они почему-то решили делать per-voucher. Вероятно, mifi прав, и в буржуинских условиях один журнал в 90% случаев содержит один ваучер, и экономия бы слишком мелкая получилась бы.

[mazzy]

Цитата:

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

Посмотрите в таблицы LedgerBalance(Dim)Trans, там несколько записей на одну дату и (комбинацию аналитик).

Да. Денис (fed) как раз и пишет, что появилось поле Variant со значениями 1..20
при помощи этого поля попытались уменьшить вероятность блокировок.

раньше, чтобы найти промежуточную сумму, нужно было сделать find.
теперь - нужно сделать sum() с разными Variant.

Но фундаментальный механизм работы с промежуточными финансовыми итогами не изменился.
1. программист говорит - вставь запись (ключевые-поля, изменения-сумм)
2. поскольку у сумм установлено свойство relative
2.1. система ищет существующую запись с этими ключевыми полями
2.2. если находит, то выполняет update полей со свойством relative (со всеми полагающимися блокировками)
2.3. если не находит, то выполняет insert

разница между старыми и новыми версиями только в случайном параметре Variant.
Этот параметр уменьшает вероятность попадания на шаг 2.2. Но ни в коем случае не исключает этот шаг.

Цитата:

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

P.S. я имею в виду опрацию из ГК-переодические операции-пересчет промежуточных сальдо (или как там она по-русски называется)

Да. Я понял что имеется в виду.
Но эта операция - очень тяжелая. Она блокирует все и надолго.
Она скорее призвана исправить ситуации, нежели является регламентной.

Промежуточные итоги могут содержать неактуальные значения в двух случаях:
1. программист использовал doUpdate, doInsert, doDelete вместо нормальных Update, Insert, Delete на таблице LedgerTrans
2. программист изменял записи в LedgerTrans прямыми запросами в SQL.

Если выполняется нормальная и штатная работа с LedgerTrans, то система всегда держит промежуточные итоги актуальными.

Цитата:

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

Насколько я помню, fieldUpdate==relative работает только в том случае если выполняется команда: UPDATE. команде INSERT на этот relative глубоко безразлично. Я НИ ОДНОГО UPDATE в системе по ledgerBalances* не нашел.

relative работает при любой операции write.
write - это тоже наследие конкорда.

ты попробуй

Цитата:

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

Есть шансы что этот relative просто незаметили и он там остался еще со времен Конкорда.

без relative работать не будет.
попробуй. создай свою табличку и изнасилуй ее

Цитата:

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

Вообще - похоже что petr прав. Авторы предполагали что балансы периодически пересчитываются и упаковываются. Вот это надо будет написать отдельной записью в блоге...

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

Цитата:

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

Кстати - а зачем тогда авторы добавили recId в конец вроде бы уникального от природы индекса по значимым полям ?
У меня попытка удалить из индекса recId с сохранением уникальности - жостко обломалась...

не знаю.

[mazzy]

наше обсуждение превращается в теологическое.
в том смысле, что делаем выводы на основании своих представлений, а не на основании практических экспериментов.

[petr]

Если на разноску одного документа (журнала, закупки и т.п.) создавать один ledgerVoucher даже если в этом документе больше одного ваучера (voucher), а это сейчас возможно, то нет разницы где сбрасывать содержимое ledgerBalanceTransDelta в ledgerBalance(Dim)Delta в ledgerVoucher.post() или в ttscommit. Все равно это код будет вызваться только один раз.

[S.Kuskov]

Цитата:

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

Кстати - а зачем тогда авторы добавили recId в конец вроде бы уникального от природы индекса по значимым полям ?

Зачем нужен уникальный index, содержащий RecId?

[petr]

Цитата:

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

Да. Я понял что имеется в виду.
Но эта операция - очень тяжелая. Она блокирует все и надолго.
Она скорее призвана исправить ситуации, нежели является регламентной.

mazzy, я не хочу ни с кем в этой ветке спорить. Все что я написал сводится в простому правилу: Если вы хотите, чтобы в пятерке отчеты использующие таблицы сальдо ledgerBalances(Dim)Trans работали быстро, надо переодические запускать операцию пересчета балансов из переодических операций ГК.

В таком случае и получиться ситуация которую бы хотел Glibs, на один день и комбинацию аналитик будет одна запись в ledgerBalances(Dim)Trans.

В принципе меня именно его пост и подтолкнул присоединиться с этому обсуждению.

P.S. Кстати разработчики много чего оптимизировали в пятерке, может быть эта операция теперь и не такая тяжелая

[Ivanhoe]

Цитата:

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

...
Да. Я понял что имеется в виду.
Но эта операция - очень тяжелая. Она блокирует все и надолго.
Она скорее призвана исправить ситуации, нежели является регламентной.

Промежуточные итоги могут содержать неактуальные значения в двух случаях:
1. программист использовал doUpdate, doInsert, doDelete вместо нормальных Update, Insert, Delete на таблице LedgerTrans
2. программист изменял записи в LedgerTrans прямыми запросами в SQL.

Если выполняется нормальная и штатная работа с LedgerTrans, то система всегда держит промежуточные итоги актуальными.

Давно мучает вопрос: если это чисто технологическая операция по исправлению ну совсем уж ошибок программистов / ручных корректировок в БД, то почему ее не только включили в Проверку целостности, а еще и вывели прямо в модуль и справочник периодов?

И, насколько я понял предположение petr, регламентный запуск процедуры нужен не для исправления ошибок, а для группировки записей. Собственно, проверено экспериментально: если было несколько записей на одну дату / счет в LedgerBalancesTrans, то после выполнения пересчета периода остается одна строка.

[fed]

Цитата:

Сообщение от S.Kuskov

Зачем нужен уникальный index, содержащий RecId?

Бесполезно цитировать мне самого себя. В исходной теме обсуждалось зачем добавлять уникальность в неуникальные индексы. Тут mazzy (если я его правильно понимаю) пытается доказать что в Аксапте insert в ledgerBalancesDimTrans магическим образом заменяется на update и несколько одинаковых записей превращаются в одну. Я задаю логичный, как мне кажется, вопрос:Если у нас и так для данной комбинации счета, аналитики, даты, вида учета и признака закрывающего периода и так обеспечивается уникальность (благодаря волшебной замене insert на update), то зачем же тогда нам нужно было добавлять recId в и без того уникальную комбинацию полей ?

[fed]

Цитата:

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

наше обсуждение превращается в теологическое.
в том смысле, что делаем выводы на основании своих представлений, а не на основании практических экспериментов.

Ну я вот тут практический эксперимент поставил: В живой и активно работающей БД версии 2009 вытащил кэш запросов. Не буду биться об заклад за какое время там запросы, но судя по полю с датой и временем последнего исполнения - самые старые запросы в кэше от позавчера. Так что рискну предположить что выборка репрезентативная. Так вот - ни одного update по ledgerBalancesDimTrans не присутствует. Есть море (порядка 8000) запросов типа:
INSERT INTO LEDGERBALANCESDIMTRANS (ACCOUNTNUM,PERIODCODE,TRANSDATE,DIMENSION,DIMENSION2_,DIMENSION3_,DIMENSION4_,SYSTEMGENERATEDULTIMO,DEBITMST,CREDITMST,DEBITOPRMST,CREDITOPRMST,DEBITTAXMST,CREDITTAXMST,DEBITMSTSECOND,CREDITMSTSECOND,DEBITOPRMSTSECOND,CREDITOPRMSTSECOND,DEBITTAXMSTSECOND,CREDITTAXMSTSECOND,QTY,DATAAREAID,RECVERSION,RECID)SELECT F1,F2,F3,F4,F5,F6,F7,F8,F9,F10,F11,F12,F13,F14,F15,F16,F17,F18,F19,F20,F21,DATAAREAID,RECVERSION,RECID+5676742945 FROM [#ax_tmp_kdis547_330_0]
Есть аналогичное количество запросов вида:
SELECT A.LEDGERACCOUNTNUM AS f1,A.PERIODCODE AS f2,A.TRANSDATE AS f3,A.DIMENSION AS f4,A.DIMENSION2_ AS f5,A.DIMENSION3_ AS f6,A.DIMENSION4_ AS f7,A.SYSTEMGENERATEDULTIMO AS f8,A.DEBITMSTSUMMED AS f9,A.CREDITMSTSUMMED AS f10,A.DEBITOPRMSTSUMMED AS f11,A.CREDITOPRMSTSUMMED AS f12,A.DEBITTAXMSTSUMMED AS f13,A.CREDITTAXMSTSUMMED AS f14,A.DEBITMSTSECONDSUMMED AS f15,A.CREDITMSTSECONDSUMMED AS f16,A.DEBITOPRMSTSECONDSUMMED AS f17,A.CREDITOPRMSTSECONDSUMMED AS f18,A.DEBITTAXMSTSECONDSUMMED AS f19,A.CREDITTAXMSTSECONDSUMMED AS f20,A.QUANTITYSUMMED AS f21,N'era' AS DATAAREAID,1 AS RECVERSION,IDENTITY(bigint,1,1) AS RECID INTO [#ax_tmp_kdis547_330_0] FROM LEDGERBALANCESDIMTRANSDELTASUM A WHERE ((DATAAREAID=N'era') AND (USERTTSID=5708989947))

То есть - система в полном соответствии с теорией обработала оператор insert_recordset из ledgerBalancesTransDelta.transferTempDeltaRecsToLedger*. Сначала выбрала просуммированные данные из view построенного поверх ledgerBalancesTranDelta во временную таблицу. Потом данные из временной таблицы ВСТАВИЛА в таблицу балансов...

[mazzy]

Цитата:

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

Тут mazzy (если я его правильно понимаю) пытается доказать что в Аксапте insert в ledgerBalancesDimTrans магическим образом заменяется на update и несколько одинаковых записей превращаются в одну.

Цитата:

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

Ну я вот тут практический эксперимент поставил...

Ок. Беру паузу. Практический эксперимент попробую сделать ночером.

[AlexSD]

Цитата:

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

наше обсуждение превращается в теологическое.
в том смысле, что делаем выводы на основании своих представлений, а не на основании практических экспериментов.

Попробывал - не получилось.
Создал в ax2009 таблицу с двумя полями: текстовое Id, числовое Amount с FieldUpdate = Relative. Уникальный индекс по полю Id.
Джобом пытаюсь добавлять, обновлять запись разными способами - никак не получается воспроизвести ситуацию, что бы поле Amount обновлялось с учетом предыдущего значения. Каждый раз значение поля переписывается.

Может, я что-то не так делаю?

[mazzy]

Цитата:

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

Попробывал - не получилось.

опаньки. понял. тем более, надо попробовать. вдруг, это я неправ.

[glibs]

Цитата:

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

...
Но, раз в день, неделю, месяц можно запускать переодический пересчет балансов, который "просуммирует" все данные в LedgerBalance(Dim)Trans на одну запись в день.
...

Не проверял, но почти уверен, что это актуально и для 4.0 чтобы схлопнуть 20 вариантов.

[fed]

Цитата:

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

Попробывал - не получилось.
Создал в ax2009 таблицу с двумя полями: текстовое Id, числовое Amount с FieldUpdate = Relative. Уникальный индекс по полю Id.
Джобом пытаюсь добавлять, обновлять запись разными способами - никак не получается воспроизвести ситуацию, что бы поле Amount обновлялось с учетом предыдущего значения. Каждый раз значение поля переписывается.

Может, я что-то не так делаю?

Кстати мне очень непонятно как fieldUpdate==relative будет работать в версиях начиная с 3.0, в которой ввели обязательность select forupdate перед update. Получается что если у тебя пессимистичный контроль для таблицы стоит, то никто кроме тебя эту запись и не сможет изменить. Если оптимистический - то у тебя при апдейте (если эту запись кто-то обновил) должен exception::updateConflict подняться. Получается что этим механизмом можно пользоваться только если skipTTSCheck(true) у таблицы врубить и табличку апдейтить после обычного select (без forupdate/pessimisticLock/optimisticLock).
Можно конечно предположить что mazzy прав и система магически умеет заменять вставки на обновления, но как-то это никак не вяжется с содержанием хэлпов всех версий...

[mazzy]

Цитата:

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

Кстати мне очень непонятно как fieldUpdate==relative будет работать в версиях начиная с 3.0...

хм... быстро обозрел

в ax2009 действительно сильно заморочено. И надо разбираться.
в ax3.0 был метод класса LedgerVoucherBalancesList.write()

private void write()
{
    LedgerBalancesMap  ledgerBalancesLocal = ledgerBalances.data();
    ;
    ttsbegin;

    this.forUpdate(ledgerBalancesLocal);

    if (!ledgerBalancesLocal)
    {
        ledgerBalancesLocal.LedgerAccount   = ledgerBalances.LedgerAccount;
        ledgerBalancesLocal.TransDate       = ledgerBalances.TransDate;
        ledgerBalancesLocal.PeriodCode      = ledgerBalances.PeriodCode;
        ledgerBalancesLocal.LedgerSystemGeneratedUltimo = ledgerBalances.LedgerSystemGeneratedUltimo;
        ledgerBalancesLocal.LedgerBalancesVariant = variant;
    }

    ledgerBalancesLocal.DebitMST        += ledgerBalances.DebitMST;
    ledgerBalancesLocal.CreditMST       += ledgerBalances.CreditMST;
    ledgerBalancesLocal.DebitOPRMST     += ledgerBalances.DebitOPRMST;
    ledgerBalancesLocal.CreditOPRMST    += ledgerBalances.CreditOPRMST;
    ledgerBalancesLocal.DebitTaxMST     += ledgerBalances.DebitTaxMST;
    ledgerBalancesLocal.CreditTaxMST    += ledgerBalances.CreditTaxMST;

    ledgerBalancesLocal.DebitMSTSecond      += ledgerBalances.DebitMSTSecond;
    ledgerBalancesLocal.CreditMSTSecond     += ledgerBalances.CreditMSTSecond;
    ledgerBalancesLocal.DebitOPRMSTSecond   += ledgerBalances.DebitOPRMSTSecond;
    ledgerBalancesLocal.CreditOPRMSTSecond  += ledgerBalances.CreditOPRMSTSecond;
    ledgerBalancesLocal.DebitTaxMSTSecond   += ledgerBalances.DebitTaxMSTSecond;
    ledgerBalancesLocal.CreditTaxMSTSecond  += ledgerBalances.CreditTaxMSTSecond;

    LedgerBalancesLocal.LedgerQty += ledgerBalances.LedgerQty;

    ledgerBalancesLocal.write();

    ttscommit;
}

Увидев его я сильно засомневался в свойстве Relative.
Интересно. Ночером.

[glibs]

Цитата:

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

...
Я в общем-то с тобой согласен. Но все равно это не остатки в наличии которые при каждой складской операции проверяются, а некая информация которая нужна ограниченому кругу лиц (2-3-4 финансиста, наверное еще 3-4-5 менеджеров), не постоянно, а время от времени. И вот получается что эти таблицы балансов пользу приносят небольшому количеству пользователей, а вред (за счет увеличения - пусть небольшого) времени разноски - почти всем пользователям (уж процентов 70 пользователей-то всяко какие-то проводки в системе создают время от времени).
...

Ах так?

Предлагаю тогда реализовать вашу идею с выборкой данных по проводкам в ГК с на промышленной БД с внушительным количеством проводок ГК, и дать бухгалтерам похлопать формой плана счетов с корректно настроенным отображением сальдо по счету. Желательно сразу несколько посадить их чтобы одновременно хлопали.

Посмотрим, чем они вас отблагодарят. И что вам скажет дисковый массив сервера БД.

Еще можно попробовать поставить на счетах проверку сальдо. Типа обязательное неотрицательное сальдо. И посмотреть как скоро начнут разноситься журналы ГК с большим количеством операций. Да и любые журналы, которые порождают проводки в ГК (те же складские).

[fed]

Цитата:

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

Ах так?

Предлагаю тогда реализовать вашу идею с выборкой данных по проводкам в ГК с на промышленной БД с внушительным количеством проводок ГК, и дать бухгалтерам похлопать формой плана счетов с корректно настроенным отображением сальдо по счету. Желательно сразу несколько посадить их чтобы одновременно хлопали.

Посмотрим, чем они вас отблагодарят. И что вам скажет дисковый массив сервера БД.

Еще можно попробовать поставить на счетах проверку сальдо. Типа обязательное неотрицательное сальдо. И посмотреть как скоро начнут разноситься журналы ГК с большим количеством операций. Да и любые журналы, которые порождают проводки в ГК (те же складские).

Сальдо в форме плана счетов просто не место. Контроль неотрицательности сальдо - забавная штука. Никогда в своей практике не пользовался. Похоже что нормального контроллинга с его помощью просто не организуешь, а накладняк на проверку - приличный.
К слову сказать - не понятно за что ты так бьешься. Ведь мы уже выяснили что обычно размеры сопоставимы. Даже если размер ledgerBalancesDimTrans составляет скажем 15-20% от размера ledgerTrans, время выполнения запроса по ней не падает в 5 раз. Время запроса с ростом таблицы растет (и падает) не совсем линейно (вспомни хотя бы про распараллеливание запросов в SQL).
То есть - ты мне с горячностью рассказываешь про преимущества, которых мы все равно лишились еще во времена выхода 3.0. Не очень понятно чего теперь меня за советскую власть аггитировать...

[glibs]

Цитата:

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

...
Сальдо в форме плана счетов просто не место.
...

Неправильные пчелы делают неправильный мед значит.

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

Нет уж. Сдавайтесь. Зря итоговые таблицы обидели.

petr прав, все сделали по уму.

[Vadik]

Цитата:

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

К слову сказать - не понятно за что ты так бьешься. Ведь мы уже выяснили что обычно размеры сопоставимы

Да вот не всегда. Для небольшой инсталляции (полторы проводки в день по счету) таки да - что проводки просканировать, что балансы - разница несущественная, но там при любом подходе проблем с производительностью нет. Для большой (сотни а еще лучше тысячи проводок в день по счету - касса к примеру или производство) после пересчета балансов разница будет. Плюс LedgerBalancesXXX таблицы лучше сжимаются средствами БД за счет того, что в них нет такого безусловно важного хлама как текст проводки, номера журналов и пр. Я не сталкивался с инсталляциями на которых есть серьезные проблемы с получением остатков\оборотов по ГК, но технологически вроде все сделано логично и с запасом "на вырост". Вот только пересчет балансов "очеловечили" бы, снабдив параметрами для задания периода - весь LedgerTrans перелопачивать каждый раз некрасиво как-то