dynamicsmatters: Performance and InventDim

[TasmanianDevil]

Цитата:

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

Нет, не пугает.
Это реляционные таблицы и реляционные СУБД.

В курсе, раздел "простейшие одноклеточные"
Я скорее всего не совсем внятно выразился, не добавление , а его следствие пугает - общее число уровней аналитики, используемых в проводках, возрастает более быстрыми темпами, чем максимальное число одновременно используемых уровней.
Тип счета в общем журнале или группировка в профилях разноски ОС и номенклатуры - есть зло ? Может быть для работы ними с каждого типа счета/группировки создать отдельное поле ссылки согласно классике одноклеточного мира ? Мое предложение расширяет уже используемую технологию с единичной ссылки до массива ссылок.

Цитата:

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

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

Enum не в коде, он в AOT, и использовать его предлагается как раз в таблице настроек моделей(массив на основе этого Enum), определяя какой уровень складской аналитики ссылается на какой справочник. В дальнейшем, в создаваемых строках документов, где есть привязка к складской аналитике, упомянутый массив из модели складской аналитики, соответствующей номенклатуре строки документа, скопируется в соответствующий массив в InventDim и, согласно прописанных Relations, определит поведение lookup при выборе на соответсвующем уровне аналитики.
Где Вы его увидели Enum в коде и отказ от таблицы настроек складских моделей ?

Цитата:

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

Полей ему жалко, а 8тыс евро на инструменты разработки не жалко...

На MoprhX - не жалко, на Аксапту - иногда жалко

Цитата:

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

Какой блин, enum? Вы посмотрите на настройку групп складской аналитики и на то сколько там параметров? Куда эти параметры девать будете?

Вместо полей InventDimSetupItemDim - несколько полей с единым EDT-масивом аналогичной размерности на Enum NoYes в настройке группы складских моделей обеспечит идентичную функциональность настроек.

Цитата:

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

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

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

Цитата:

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

Какой блин, enum? Как секьюрити будете раздавать? Как RLS включать?...

Секьюрити на уровни аналитики складской ? Можно в студию пример бизнес-процесса, когда понадобится раздавать разный доступ на разные уровни ?
В одном заказе один менеджер выбирает цвет, второй менеджер размер, а знать, что выбрал другой, им не позволительно ?
Не представляю такой ситуации в принципе ...
А что с RLS не так ? Запрос при lookup на таблицы-справочники разрезов складской аналитики как строился согласно Relations на InventDim так и будет строиться, RLS как отрабатывал - так должен отработать.Настраивать RLS для строк документа, имеющих ссылку на складскую аналитику, в зависимости от ее значений ? Не всегда подобное необходимо, хотя если припрет - да, сложнее станет, но отнюдь не смертельно.

Цитата:

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

Какой блин, enum? Как индексы ставить будете?

ItemId, поле-массив Enum'ов, поле-массив ссылок - пока в ограничения платформы не упрется.
Такой вот , блин, enum.

Цитата:

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

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

7 лет администрирования Галактики с именно такой архитектурой аналитики. Видел запросы и писал сам. Сложнее , но не смертельно.
Вырабатывает дисциплинированность и внимательность.

Цитата:

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

Зла не хватает...

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

P.S.

Цитата:

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

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

Поменять мне, что ли, login на AxForum на "Оптимизатор Хренов" или "Программист Хренов" ?
Буду как один академик-атомщик на заре становления атомной отрасли, из-за секретности он был под псевдонимом Хренов. Вот поди потешался мужик, при отправке докладов в политбюро

[mazzy]

Цитата:

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

В курсе, раздел "простейшие одноклеточные"
Я скорее всего не совсем внятно выразился, не добавление , а его следствие пугает - общее число уровней аналитики, используемых в проводках, возрастает более быстрыми темпами, чем максимальное число одновременно используемых уровней.

Наверное, я тормоз. Ну и что?

Цитата:

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

Тип счета в общем журнале или группировка в профилях разноски ОС и номенклатуры - есть зло ? Может быть для работы ними с каждого типа счета/группировки создать отдельное поле ссылки согласно классике одноклеточного мира ? Мое предложение расширяет уже используемую технологию с единичной ссылки до массива ссылок.

Не понимаю.
Может создадите новую ветку и выскажетесь подробно и с аругментами?

Цитата:

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

Enum не в коде, он в AOT, и использовать его предлагается как раз в таблице настроек моделей(массив на основе этого Enum), определяя какой уровень складской аналитики ссылается на какой справочник. В дальнейшем, в создаваемых строках документов, где есть привязка к складской аналитике, упомянутый массив из модели складской аналитики, соответствующей номенклатуре строки документа, скопируется в соответствующий массив в InventDim и, согласно прописанных Relations, определит поведение lookup при выборе на соответсвующем уровне аналитики.
Где Вы его увидели Enum в коде и отказ от таблицы настроек складских моделей ?

тогда ничего не понимаю
схему данных можно?

Цитата:

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

Секьюрити на уровни аналитики складской ? Можно в студию пример бизнес-процесса, когда понадобится раздавать разный доступ на разные уровни ?
В одном заказе один менеджер выбирает цвет, второй менеджер размер, а знать, что выбрал другой, им не позволительно ?
Не представляю такой ситуации в принципе ...

Зря. Менеджер не указывает серийных номеров, а кладовщик работает с ними в обязаетльном порядке. На одном сайте работают с партиями, а в другом их игнорируют.

Цитата:

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

А что с RLS не так ? Запрос при lookup на таблицы-справочники разрезов складской аналитики как строился согласно Relations на InventDim так и будет строиться, RLS как отрабатывал - так должен отработать.Настраивать RLS для строк документа, имеющих ссылку на складскую аналитику, в зависимости от ее значений ? Не всегда подобное необходимо, хотя если припрет - да, сложнее станет, но отнюдь не смертельно.

Т.е. вы не предлагаете отказаться от InventDim?
Ничего не понимаю.

Цитата:

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

7 лет администрирования Галактики с именно такой архитектурой аналитики. Видел запросы и писал сам. Сложнее , но не смертельно.
Вырабатывает дисциплинированность и внимательность.

опять же - схему данных можно посмотреть?

Цитата:

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

Поменять мне, что ли, login на AxForum на "Оптимизатор Хренов" или "Программист Хренов" ?
Буду как один академик-атомщик на заре становления атомной отрасли, из-за секретности он был под псевдонимом Хренов. Вот поди потешался мужик, при отправке докладов в политбюро

Почему бы и нет? Пишите в личку.

[belugin]

Очень интересная дискуссия, давайте как- то зафиксируем промежуточные результаты?

1. Щас есть два решения для хранения аналитик - InventDim и Dimensions

2. Недостатки InventDim

- требуется лишний джоин
интересно, есть ли данные насколько такой джоин дорог в количественном отношении?

- невозможность пострения составного индекса для поиска по полю таблицы и полю InventDim
для запросов типа

select * from InventTrans 
     where InventTrans.ItemID == _itemID
     join InventDim 
             where InventTrans.InventDimID ==  InventDim.InventDimID
                      &&
                       InventDim.InventLocationID == _inventLocationID

тут нельзя сделать составной индекс по <ItemID, inventLocationID> так как они в разных таблицах
Это мне кажется ограничение скорее аксапты - в SQL server, насколько я знаю, есть возможность строить индексы по функциям общего вида => мало что мешает строит индексы по полю связанной таблицы

- требуется лазить в дополнительную таблицу для получения оттуда данных

3. Недостатки Dimensions

- если объем InventDim существенно меньше объема inventTans, то inventTrans распухнет при переходе к схеме Dimensions (с другой стороны, есть менее постоянные аналитики, для которых это оправдано)

- нетипизированность ( все значения должны быть одного размера) - это ограничение наложенное аксаптой так как нет типа "структура" а есть тип "массив"

4. недостатки перехода InventDim --> Dimensions

- отвалятся модификации использующие существующую архитектуру

Я все правильно понял или что-то упустил?

С моей точки зрения недостатки inventDim в какой-то степени можно нивелировать развитием движка аксапты, SQL сервера или возможности использования второго первым...

[mazzy]

Цитата:

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

Я все правильно понял или что-то упустил?

Вроде правильно.
Спасибо за резюме.
Надо подумать.

[kashperuk]

Цитата:

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

3. Недостатки Dimensions
- нетипизированность ( все значения должны быть одного размера) - это ограничение наложенное аксаптой так как нет типа "структура" а есть тип "массив"

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

[belugin]

Цитата:

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

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

Вот я имею ввиду сделать Edt типа структура. она ведет себя как таблица при редактировании из АОТ а при добавлении в таблицу просто включенные в нее поля добаляются этой таблице. А потом образщаться типа:

inventTrans.SelectiveDims.SerialNo

[egorych]

Цитата:

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

Это мне кажется ограничение скорее аксапты - в SQL server, насколько я знаю, есть возможность строить индексы по функциям общего вида => мало что мешает строит индексы по полю связанной таблицы

Сейчас полазил по доке на SQL на предмет освежить сведения по индексам - что-то не нашел такой возможности ! Для такого вида запросов наилучшим решением были-бы индексированные вьюшки - они действительно дают большой прирост производительности.

[belugin]

Вот это Creating Indexes on Computed Columns

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

Другое дело что проблему "селективных аналитик" это не решит - InventDim будет пухлым.

Возможно стоит сделать, чтобы селективные были в типа Dimension, а неселективные - в InventDim.

только надо предусмотреть некоторый путь перехода для модифицированного кода от текущей ситуации к этой новой.

Тут такие мысли:

1. Найти такой код легко - он просто перестанет компилироваться

2. Для корректно написынных форм с редактированием InventDim можно, наверное, сделать автоматический конвертер

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

[Logger]

Коллеги, а как была релизована аналитика в XAL ?
В упомянутом блоге Sven ссылается на XAL.

Плюс интересно сравнить с Oracle и SAP

Кто в курсе как там реализованы аналитики ?

[mazzy]

Цитата:

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

Коллеги, а как была релизована аналитика в XAL ?
В упомянутом блоге Sven ссылается на XAL.

Конфигурация была отдельным полем.
Размера и цвета не было.
Склад, Серийный номер, Партия, Паллета, Ячейка были в inventDim.

ГТД локализаторы также затолкали в InventDim (в Аксапту решение было перенесено из XAL). По этому поводу сильно возмущался Pavel, насколько я помню. Насколько я помню, одно из преимуществ альтернативной локализации XAL, которое предлагал Pavel, это - другая реализация работы с ГТД.

Цитата:

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

Плюс интересно сравнить с Oracle и SAP.
Кто в курсе как там реализованы аналитики ?

Не знаю точно, но по моему отдельными полями и таблицами. Универсального механизма нет.

В Навижине InventDim'а точно нет, есть специализированные поля, специализированные таблицы и специализированные индексы для каждой аналитики.

[glibs]

Цитата:

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

...
Конфигурация была отдельным полем.
Размера и цвета не было.
Склад, Серийный номер, Партия, Паллета, Ячейка были в inventDim.
...

Я так понимаю, речь тут идет о 2.5. Просто для меня это не очевидно. Думаю, стоит обратить внимание остальных участников на этот момент.

[glibs]

Цитата:

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

...
Коллеги, а как была релизована аналитика в XAL ?
В упомянутом блоге Sven ссылается на XAL.

Плюс интересно сравнить с Oracle и SAP

Кто в курсе как там реализованы аналитики ?
...

Если уйти из практической и прикладной области (которую в отношении к Аксапте описал fed) в обсуждении вопроса про аналитики, то для "безразмерных" аналитик возможен еще такой вариант их реализации.

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

Соответственно для каждой проводки хранится n записей в списке аналитик.

Видел такое в одной из систем. На практике не пробовал. Да в то время у меня и навыков таких еще не было.

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

А вообще в теории задачи грубо делятся на транзакционные (OLTP) и аналитические (OLAP). Ну и, как правило, если на некой структуре данных транзакционные операции выполняются оптимально, то аналитические тормозят. Или наоборот. Для OLAP самой эффективной с т.з. производительности структурой является MOLAP, как известно из теории. Это когда всего одна таблица со всеми возможными измерениями. Она же самая затратная с т.з. потребления места на диске. Она является противоположностью реляционным многотабличным структурам. И неудобна для транзакционных операций (скорость изменения данных, блокировки, и т.п.).

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

В общем, не стоит искать более правильную структуру (если в текущую не были заложены ошибки). Если упростить до двух структур и двух ситуаций, то в первой ситуации Структура 1 будет эффективной, а Структура 2 неэффективной. Во второй ситуации будет наоборот. Это как сравнивать Камаз и Жигули. Или самолет и автомобиль.

Это упрощенно, "на счетных палочках", но примерно так и есть на самом деле.

В свете темы ответственности за свои советы, которую поднял Маззи, еще раз повторю. Это были некоторые теоретические выкладки. "Пища для размышлений". Чтобы адекватнее воспринимать окружающий мир. Прикладной аспект осветил fed.

[mazzy]

Цитата:

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

Я так понимаю, речь тут идет о 2.5. Просто для меня это не очевидно. Думаю, стоит обратить внимание остальных участников на этот момент.

Вопрос был про XAL. Ответ был тоже про XAL.

Цитата:

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

В проводках аналитик нет вообще. Зато есть отдельная таблица, в которой структура примерно такая:
- ссылка на таблицу проводок

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

Цитата:

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

Думать на эту тему лениво.

Оно и видно

[glibs]

Цитата:

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

...
Вопрос был про XAL. Ответ был тоже про XAL.
...

Значит показалось. Но в 2.5 еще было именно так. Только в InventDim еще и ГТД была уже.

[belugin]

И вообще, должен придти fed и расставить все на свои места!

[belugin]

TasmanianDevil, я правильно понял, что одно и то же поле будет в таблице иметь разный смысл (и конуептцально тип) в зависимости от настроек конфигурации?

А как интересно будет выглядеть тогда запрос "выбрать все с данного слклада"

select x from t1 where 
   (dimType[1] == DimType::Location && dimValue[1] == _location)
   ||
   (dimType[2] == DimType::Location && dimValue[2] == _location)
   ||
   (dimType[2] == DimType::Location && dimValue[2] == _location)

Не снесет ли крышу оптимизатору в данном случае?

[TasmanianDevil]

Цитата:

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

TasmanianDevil, я правильно понял, что одно и то же поле будет в таблице иметь разный смысл (и конуептцально тип) в зависимости от настроек конфигурации?

А как интересно будет выглядеть тогда запрос "выбрать все с данного слклада"

select x from t1 where 
   (dimType[1] == DimType::Location && dimValue[1] == _location)
   ||
   (dimType[2] == DimType::Location && dimValue[2] == _location)
   ||
   (dimType[2] == DimType::Location && dimValue[2] == _location)

Не снесет ли крышу оптимизатору в данном случае?

При решении в лоб и достижении некоего кол-ва уровней - снесет без вопросов.
Решения :
1) Увеличить кол-во запросов (N уровней -N запросов)
2) Общие для всех моделей разрезы аналитики использовать в едином для всех разрезе(порядок и уровень). Допустим общие у нас разрезы - это "склад" и "кладовщик", первым уровнем для всех моделей будет "склад", вторым - "кладовщик". Экзотику , специфичную для каждой конкретной модели опускать на нижние уровни.
У обоих вариантов есть недостатки - но их можно считать это платой за универсальность

[fed]

В общем - в подробности я пока лезть не буду (времени нету), но по моему при подобной степени модификации Аксапты, дальнейшие затраты на поддержку и развитие системы, превысят стоимость ОЧЕНЬ крутого сервера БД. При нынешнем росте зарплат в России, инвестиции в железо в 95% случаев оказываются выгоднее, чем затраты на оптимизацию.

[belugin]

Цитата:

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

В общем - в подробности я пока лезть не буду (времени нету)

Имеется ввиду модификация автора блога или про энамы?

[fed]

Цитата:

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

Имеется ввиду модификация автора блога или про энамы?

Да в общем - имелись в виду любые модификации, связанные со слишком глубоким изменением существующего подхода к работе со складскими проводками и складской аналитике Из любви к искусству обсуждать "как бы было правильно спроектировать Аксапту", мне жалко времени. Все равно - Аксапта такая какая она есть и ее достоинства являются продолжением ее недостатков. Практической ценности в такой дискуссии не очень много, потому что с точки зрения стоимости владения, подобные переработки явно проигрывают замене железа на более мощное или использованию трюков, связанных с тонкой настройкой БД (скажем тех же clustered indexed view в SQL Server или Index Cluster/Hash Cluster в Oracle).

Кстати - вот одна из моих любимых статей в jargon file:
http://www.catb.org/~esr/jargon/html/B/brute-force.html