fed: Ledger Balance Data in DAX

[glibs]

Кстати, насколько я заметил краем глаза в 5.0 убрали 20-кратное раздутие LedgerBalancesDimTrans. Судя по таблице LedgerBalancesTransDelta в таблице итогов без аналитик с блокировками решили бороться тем же способом, как и в InventSum в 4.0.

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

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

[fed]

Цитата:

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

Кстати, насколько я заметил краем глаза в 5.0 убрали 20-кратное раздутие LedgerBalancesDimTrans. Судя по таблице LedgerBalancesTransDelta в таблице итогов без аналитик с блокировками решили бороться тем же способом, как и в InventSum в 4.0.

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

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

Гы ! Так я о том и пишу. В версии 2009 ОДНУ запись в балансовые таблицы пишут на ОДИН ваучер! Так что эти 20 записей (если ты уж так обеспокоен размером этой таблицы) это еще немного было... Не веришь - попробуй в 2009ой найти команды ОБНОВЛЕНИЯ балансов. Я долго не верил своим глазам - но оказалось что там только ВСТАВКИ.

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

[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 перелопачивать каждый раз некрасиво как-то

[Ivanhoe]

Цитата:

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

... Вот только пересчет балансов "очеловечили" бы, снабдив параметрами для задания периода - весь LedgerTrans перелопачивать каждый раз некрасиво как-то

Пересчет можно запустить из формы периодов по конкретному периоду

[glibs]

Цитата:

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

...
Ведь мы уже выяснили что обычно размеры сопоставимы. Даже если размер ledgerBalancesDimTrans составляет скажем 15-20% от размера ledgerTrans, время выполнения запроса по ней не падает в 5 раз.
...

Давайте найдем большую БД и проверим.

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

[fed]

Цитата:

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

Давайте найдем большую БД и проверим.

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

Ну насчет кластерных индексов - как раз сомнительно. Если у тебя стандартный индекс accountNum+dimension, а я ищу выборку по AccountNum+dimension[2], то индекс будет использоваться только для отбора всех проводок по счету. Фильтрация по аналитике будет делаться уже за счет данных, а не за счет индекса. И если условие по dimension[2] высокоселективно, то надо по нему индекс строить (типа transDate+accountNum+dimension[2]) (независимо от того - ищем мы по ledgerTrans или ledgerBalancesDimTrans). Может заметно быстрее получиться - несмотря на лукап... Кстати - длинный ключ кластерного индекса по ledgerBalances тут может негативную роль сыграть...

[glibs]

Цитата:

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

...
Ну насчет кластерных индексов - как раз сомнительно.
...

Не конкретно.

Цитата:

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

...
Если у тебя стандартный индекс accountNum+dimension, а я ищу выборку по AccountNum+dimension[2], то индекс будет использоваться только для отбора всех проводок по счету. Фильтрация по аналитике будет делаться уже за счет данных, а не за счет индекса.
...

Верно. Но если индекса по AccountNum+dimension[2] нет и на LedgerTrans, а его там нет, то выборка по кластерному индексу приведет к эффекту сканирования фрагментов кластерного индекса на LedgerBalancesdimTrans. Т.е. произойдет а-ля сканирования таблицы на самом деле, но по отдельным кускам таблицы. Это оптимальный подход к выборке данных в данном случае. Да, фильтрация по данным будет.

А вот если бы индекс был некластерный, то записи будут лукапиться последовательно (сначала будет сканироваться кусками индекс, а потом будут лукапиться уже данные). В случае с кластерным индексом каждая страница с данными гарантировано считается только один раз (оптимально). А в случае с лукапом по индексу одна и та же страница может считаться много раз (зависит от ресурсов памяти, которыми располагает сервер БД и насколько много сессий он обслуживает и какую нагрузку они ему обеспечивают). Если весь LedgerTrans поместится в кеше, то запрос может и быстро отработать, но если пользователи-конкуренты его в момент запроса сильно нагрузят, то памяти на кеш на всех может не хватить, и будет прилично ввода-вывода.

Индекс некластерный эффективен при выборке одной или нескольких записей из большой таблицы.

Цитата:

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

...
И если условие по dimension[2] высокоселективно, то надо по нему индекс строить (типа transDate+accountNum+dimension[2]) (независимо от того - ищем мы по ledgerTrans или ledgerBalancesDimTrans). Может заметно быстрее получиться - несмотря на лукап
...

Я говорил про стандартные индексы. На все случаи жизни индексов не настроишь. Индексирование — дело разумного компромисса.

Если бы индекс на LedgerBalancesdimTrans был не кластерным, то на выборе из огромной таблицы нескольких записей он бы дал большую скорость. Но при выборе очень большого количества записей большую скорость даст кластерный индекс.

Цитата:

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

...
Кстати - длинный ключ кластерного индекса по ledgerBalances тут может негативную роль сыграть
...

О чем идет речь?

Блокировки? Скорость разноски на OLTP операциях?

Разумеется. OLTP оно такое. Должно учитывать интересы аналитических задач. Но при грамотной архитектуре БД тормоза OLTP пользователь не ощутит. При этом будет учтен интерес аналитических пользователей.