fed: Ledger Balance Data in DAX

[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 с сохранением уникальности - жостко обломалась...

не знаю.

[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, то после выполнения пересчета периода остается одна строка.