dynamicsmatters: Performance and InventDim

[Blog bot]

Источник: http://dynamicsmatters.blogspot.com/...inventdim.html
==============



Источник: http://dynamicsmatters.blogspot.com/...inventdim.html

[mazzy]

ужас какой-то...

[kashperuk]

На самом деле, возможно и не ужас
В смысле, конкретно эта идея может и не очень.
Но вообще в планах на 6ую версию проскакивал отказ от InventDim и вообще такого подхода.

[mazzy]

можно тогда попросить тебя изложить своими словами то, что он предложил?
может быть мой английский настолько плох, что я ни черта не понял?

[kashperuk]

Если кратко, то он предложил:

1. Удалить таблицу InventDim
2. Во всех таблицах, где есть поле InventDimId, это поле удалить, и добавить по 3 новых (с ArraySize > 1 у всех)

То есть в каждой таблице (на стороне SQL) будет вместо 1 поля 9 (или сколько там, я не посчитал)

Чем мне не нравится такой подход:
- Размер базы намного больше
- В каждой таблице больше полей, поэтому больше постоянно тянется при запросах
- Размер индексов больше, соответственно, размер базы больше и скорость меньше.
т.д.

P.S. Поздравляю с репутацией == 600!
Я бы создал в соответствущей теме это, но пора бежать на развозку.

[mazzy]

Цитата:

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

Если кратко, то он предложил:

1. Удалить таблицу InventDim
2. Во всех таблицах, где есть поле InventDimId, это поле удалить, и добавить по 3 новых (с ArraySize > 1 у всех)

То есть в каждой таблице (на стороне SQL) будет вместо 1 поля 9 (или сколько там, я не посчитал)

Угу. И все с индексами. Если я правильно понимаю, то одна из главных задач, которая решалась при созданиии InventDim - это избавиться от монстроидальных составных индексов на таблицах проводок/строк журналов/строк заказов/итогов.

Я и говорю - ужас какой-то (несмотря на мой плохой английский, понял таки правильно )

[gl00mie]

Цитата:

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

Угу. И все с индексами. Если я правильно понимаю, то одна из главных задач, которая решалась при созданиии InventDim - это избавиться от монстроидальных составных индексов на таблицах проводок/строк журналов/строк заказов/итогов.

Вместо монстроидальных индексов получили монстроидальные планы запросов, когда join'ятся несколько таблиц, в каждой из которых - миллионы записей, из-за чего в конечном итоге возникает то тут, то там денормализация данных: рядом с inventDimId в транзакционных таблицах селится inventLocationId или другие поля из InventDim. Кроме того, если на каждой таблице проводок/строк журналов/строк заказов будут свои индексы, ими будет проще управлять, даже если они будут на sys-слое. Нужно ускорить выборку по какой-то таблице в каком-то разрезе - привинтил индекс, не нужно - отключил его, и пусть болтается в AOT'е. А так выходит, что одна таблица InventDim, пухнущая не по дням, а по часам, обрастает кучей индексов на все случаи жизни...

[mazzy]

Цитата:

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

Вместо монстроидальных индексов получили монстроидальные планы запросов, когда join'ятся несколько таблиц, в каждой из которых - миллионы записей, из-за чего в конечном итоге возникает то тут, то там денормализация данных:

Хе... А это вы просто ГТД бездумно используете.
Обратите внимание, что серийные номера и партии в стандартном функционале относятся к "селективным" (там метод такой есть). А вот ГТД забыли в этот метод включить

Кроме того, обратите внимание, на отдельные запросы по селективным полям... А у ГТД опять же "забыли" сделать отдельные запросы.

Сколько раз видел, что народ добавляет свои поля, похожие на ГТД и также не указывает "селективность"... Кроме того и ГТД нельзя в InventDim запихивать. В inventDim должны присутствовать только признаки, которые можно проинвентаризировать.

"Миллионы записей в InventDim" - это ненормально.
А если уж "так получилось", то не забывайте о стандартном функционале, который позволяет работать и с такими случаями.

[Vadik]

Цитата:

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

Хе... А это вы просто ГТД бездумно используете.
Обратите внимание, что серийные номера и партии в стандартном функционале относятся к "селективным" (там метод такой есть). А вот ГТД забыли в этот метод включить

а включим ГТД в волшебный метод - и размер таблицы волшебным же образом уменьшится?


опять же - "бездумно"..
какой функционал есть, такой и используем..
или предлагаешь свой написать?

[glibs]

Цитата:

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

...
"Миллионы записей в InventDim" - это ненормально.
...

Если использовать WMS (даже без ГТД) — вполне реально. Партии и серийные номера раздувают InventDim сильно. В производстве это особенно актуально (там партии используются частенько, серийные номера иногда).

А селективность спасает только на определенных запросах. При раздутом другими аналитиками InventDim отбор проводок, которые относятся к определенному складу, например, превращается в трудоемкую задачу для сервера СУБД.

В некоторых случаях можно пытаться решать некоторые проблемы с производительностью запросов путем дублирования склада или прочих нужных аналитик в транзакции. Но это требует существенной переделки логики и предельной аккуратности. Такой подход годится для эксклюзивных случаев, в которых производительность архи-критична.

[Vadik]

Цитата:

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

Я и говорю - ужас какой-то (несмотря на мой плохой английский, понял таки правильно )

Зачем сразу "ужас". Это не ужас. Это идея, причем здравая - INVENTDIM при использовании палет или серийных номеров и есть настоящий монстр, постоянно join-ящийся к проводочным таблицам. И на нем как раз монстроидальный составной индекс DimIdx.

Вполне вероятно, что показывать (и, возможно, фильтровать) номенклатурные аналитики требуется чаще, чем аналитики хранения (по крайней мере - в пользовательском интерфейсе). Если бы малой кровью удалось переписать INVENTDIMxxx макросы (в идеале - с удалением из запроса неиспользуемых таблиц), эффект на мой взгляд мог бы быть

P.S. Ты посмотри на \Data Dictionary\Tables\InventSum\Methods\queryAddHint, \Data Dictionary\Tables\InventSum\Methods\queryAddHintFromCaller
Вот где ужас-то
P.P.S. Хотя одними макросами тут конечно не обойдется..

[mazzy]

Цитата:

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

Зачем сразу "ужас". Это не ужас. Это идея, причем здравая - INVENTDIM при использовании палет или серийных номеров и есть настоящий монстр, постоянно join-ящийся к проводочным таблицам. И на нем как раз монстроидальный составной индекс DimIdx.

Вполне вероятно, что показывать (и, возможно, фильтровать) номенклатурные аналитики требуется чаще, чем аналитики хранения (по крайней мере - в пользовательском интерфейсе). Если бы малой кровью удалось переписать INVENTDIMxxx макросы (в идеале - с удалением из запроса неиспользуемых таблиц), эффект на мой взгляд мог бы быть

Дык, они и так разными запросами join'ятся.
См. например, \Classes\InventSumFinancial\setValueQty

Цитата:

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

P.S. Ты посмотри на \Data Dictionary\Tables\InventSum\Methods\queryAddHint, \Data Dictionary\Tables\InventSum\Methods\queryAddHintFromCaller
Вот где ужас-то
P.P.S. Хотя одними макросами тут конечно не обойдется..

И сюда тоже ГТД вписать надо
Вообще говоря, ты привел методы, которые используют метод
\Data Dictionary\Tables\InventDimParm\Methods\isFlagSelective

посмотри чем он используется при помощи перекрестных ссылок. Этот метод определяет поля, поиск по которым дает очень селективную выборку. В зависимости от этого метода в Аксапте работает очень много кода для "оптимизации".

Попробуй сделать минимальную правку - добавь ГТД в метод isFlagSelective. Обрати внимание насколько изменилось поведение системы


А вообще говоря, согласен с тем, что сам InventDim - это результат программистского подхода: щас мы наваяем универсальный механизм, а пользователи его будут настраивать. Но перенести этот универсальный механизм в array - это не выход. Это тот же самый программистский подход - вид сбоку

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

[kashperuk]

Цитата:

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

Надо перерабатывать саму идеологию.

Слава богу,

Цитата:

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

разработчик

вроде как раз так и думает сделать. Что не может не радовать

[Vadik]

Цитата:

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

Дык, они и так разными запросами join'ятся.
..
посмотри чем он используется при помощи перекрестных ссылок. Этот метод определяет поля, поиск по которым дает очень селективную выборку. В зависимости от этого метода в Аксапте работает очень много кода для "оптимизации".
См. например, \Classes\InventSumFinancial\setValueQty
..
если идет фильтрация по селективному полю, то будут работать совсем другие запросы и совсем другие хинты

Знаю, поэтому и говорю - "ужас"
Мне кажется, это тупиковое направление. Особенно если учитывать возможность добавления новых "селективных" аналитик. Как например должна выглядеть логика в случае указания двух "селективных" аналитик - выбирать "наиболее селективную"?
А оптимизатор СУБД на что придуман? За него ведь "уже уплочено"..

Цитата:

Попробуй сделать минимальную правку - добавь ГТД в метод isFlagSelective. Обрати внимание насколько изменилось поведение системы

Да если бы оно от этого сильно менялось.. Индекс по номеру ГТД ведь в коде не протянули.

Цитата:

А вообще говоря, согласен с тем, что сам InventDim - это результат программистского подхода: щас мы наваяем универсальный механизм, а пользователи его будут настраивать.

Так.. опять наезды на программистов
Идея универсального механизма хорошая, но механизм пора чуток обновить с учетом того, что самих аналитик и их комбинаций чуть больше, чем задумывалось на этапе проектирования

Цитата:

Но перенести этот универсальный механизм в array - это не выход. Это тот же самый программистский подход - вид сбоку

Да, тут человек недодумал скорее всего. Потому что получение остатков в разрезе аналитик теперь невозможно - либо запрос по транзакционным таблицам, либо перенос аналитик в InventSum
Но не беда. Зато - идет мыслительный процесс

Цитата:

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

Собственно, я о том же.


Разве что с тем, что комбинаций номенклатурных аналитик больше, не совсем согласен. It depends

[TasmanianDevil]

Джентльмены, простите, что вмешиваюсь в высоконаучный спор мэтров ...

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

Массив ссылок, массив Enum(определяет на кого ссылается данный уровень аналитики и настраивается при настройке соответствующей модели складской аналитики, выбирая только нужные) одинаковой размерности и для каждого поля массива ссылок набор relations на соотвествующие таблицы согласно значений Enum - вот вполне разумный выход вместо линейного набора N-дцати полей, из которых в лучшем случае используются 3-4 одновременно.

У меня сейчас на одном проекте наколбасили аж 13 уровней аналитики складской, из которых в лучшем случае 3 одновременно используется - смотреть на эту порнографию тошно

[miklenew]

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

[mazzy]

Цитата:

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

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

Вот точно - программистский подход.
Наваять что-то универсально-монстроидальное - "а клиент пусть сам решает".
А стоимость настройки? А стоимость сопровождения? А стоимость доработок поверх этого "и так, и так"?

[miklenew]

Цитата:

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

Вот точно - программистский подход.
Наваять что-то универсально-монстроидальное - "а клиент пусть сам решает".
А стоимость настройки? А стоимость сопровождения? А стоимость доработок поверх этого "и так, и так"?

Я к тому что kashperuk сказал

Цитата:

Но вообще в планах на 6ую версию проскакивал отказ от InventDim и вообще такого подхода.

Если такие мысли будут, было бы не плохо две разных версии выпустить.
Т.к. при использовании подобного подхода клиентам перенести свои модификации на 6.0 будет не реально или весьма проблемно.

[glibs]

Цитата:

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

...
Т.к. при использовании подобного подхода клиентам перенести свои модификации на 6.0 будет не реально или весьма проблемно.
...

Если клиент думает о переходе на новую версию...

Он программировать будет с умом. И постарается много не писать. И писать правильно.

А если делать не так, то любой переход на новую версию покажется чем-то фантастическим и несбыточным. Даже если не менять революционно аналитики.

[mazzy]

Цитата:

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

9(или сколько там ) полей в складской аналитике Вас пугают , а сам принцип линейной аналитики , который при добавлении нового аналитического разреза вынуждает создавать новое поле в аналитике - нет.

Нет, не пугает.
Это реляционные таблицы и реляционные СУБД. Очень хочется послать читать теорию

Цитата:

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

А реально из этих 9 (или сколько там у Вас) сколько используются одновременно в одной проводке ? Два, три, четыре ? Тогда зачем плодить столь много ссылочных полей , большая часть которых для одной операции не заполняется ?

Для разных номенклатур заполняются разные поля.
И что в этом плохого?

"Лишние" выключаются конфигурационными ключами, секьюрити ключами, настройкой "отображение складских аналитик"

Цитата:

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

Массив ссылок, массив Enum(определяет на кого ссылается данный уровень аналитики и настраивается при настройке соответствующей модели складской аналитики, выбирая только нужные) одинаковой размерности и для каждого поля массива ссылок набор relations на соотвествующие таблицы согласно значений Enum - вот вполне разумный выход вместо линейного набора N-дцати полей, из которых в лучшем случае используются 3-4 одновременно.

Еще один деятель... Только теперь предлагает использовать жестко заданный в коде enum вместо таблицы настроек. Полей ему жалко, а 8тыс евро на инструменты разработки не жалко...

Какой блин, enum? Вы посмотрите на настройку групп складской аналитики и на то сколько там параметров. Куда эти параметры девать будете?
Какой блин, enum? Вы как выключать лишние при помощи конфигурационных ключей будете?
Какой блин, enum? Как секьюрити будете раздавать? Как RLS включать?...
Какой блин, enum? Как индексы ставить будете?

Вы предлагаете механизм, похожий на механизм субконто в 1С:Бухгалтерии.
Вы пробовали администрировать этот механизм? Вы видели эти запросы?

Оптимизаторы, блин, хреновы...
Ужас-ужас-ужас!!! Ну, продумайте до конца свою идею... Программисты, блин...

Цитата:

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

У меня сейчас на одном проекте наколбасили аж 13 уровней аналитики складской, из которых в лучшем случае 3 одновременно используется - смотреть на эту порнографию тошно

1. Не смотрите: Выключите лишние при помощи настройки "Отображение складских аналитик"
2. Не смотрите: Выключите лишние при помощи конфигурационных ключей
3. Не смотрите: Настройте ключи безопасности

Полей блин, ему жалко...
Экономика, блин, должна быть экономной, блин...
Зла не хватает...