fed: Ledger Balance Data in DAX

[petr]

Не согласен с критикой нового механизма. По-моему в MS в новой версии все прекрасно сделали.

Как я понял идея такая. Во время разноски операции ГК в таблицы LedgerBalance(Dim)Trans идет только вставка (притом очень быстрая) данных заранее уже подготовленных в LedgerBalancesTransDelta. Никаких update и подобных блокировок, плюс ускоряется разноска ваучера.

Действительно на один день может получиться очень много записей в LedgerBalance(Dim)Trans (сопоставимо по кол-ву с legderTrans, даже если аналитики вообще не используются).

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

В итоге получаем:
- таблицу сальдо LedgerBalance(Dim)Trans с одной записей на один день (как в версии 2.5 до появления поля Variant)
- при разноске журналов никаких блокировок и лишних Update-ов, только Insert

Т.е. разработчики совместили в одно механизме скорость при создании записей в таблице сальдо и минимальный объем таблицы для последующего использования для отчетов.

[mazzy]

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

Цитата:

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

Как я понял идея такая. Во время разноски операции ГК в таблицы LedgerBalance(Dim)Trans идет только вставка (притом очень быстрая) данных заранее уже подготовленных в LedgerBalancesTransDelta. Никаких update и подобных блокировок, плюс ускоряется разноска ваучера.

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

Цитата:

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

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

Не... Ни в коем случае.
Весь цимус как раз в том, что промежуточные итоги актуальны в любой момент.
(ну, только если программист не вызвал где-нибудь хакерские doUpdate, doInsert, doDelete вместо нормальных Update, Insert, Delete )

[petr]

Цитата:

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

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


petr, смотрите внимательно на свойство FueldUpdate.
там не только вставка.

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

Цитата:

Не... Ни в коем случае.
Весь цимус как раз в том, что промежуточные итоги актуальны в любой момент.
(ну, только если программист не вызвал где-нибудь хакерские doUpdate, doInsert, doDelete вместо нормальных Update, Insert, Delete )

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

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

[fed]

Цитата:

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

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


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

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

[S.Kuskov]

Цитата:

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

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

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

[fed]

Цитата:

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

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

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

не знаю.

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

[glibs]

Цитата:

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

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

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