dynamicsmatters: Performance and InventDim

[mazzy]

Цитата:

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

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

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

[miklenew]

Цитата:

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

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

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

Цитата:

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

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

[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

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

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

[Logger]

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

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

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

[mazzy]

Цитата:

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

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

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

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

Цитата:

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

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

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

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

[kashperuk]

Цитата:

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

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

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

[egorych]

Цитата:

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

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

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

[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 на "Оптимизатор Хренов" или "Программист Хренов" ?
Буду как один академик-атомщик на заре становления атомной отрасли, из-за секретности он был под псевдонимом Хренов. Вот поди потешался мужик, при отправке докладов в политбюро

[belugin]

Вот это Creating Indexes on Computed Columns

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

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

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

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

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

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

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

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

[belugin]

Цитата:

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

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

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

inventTrans.SelectiveDims.SerialNo

[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

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

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

[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 на "Оптимизатор Хренов" или "Программист Хренов" ?
Буду как один академик-атомщик на заре становления атомной отрасли, из-за секретности он был под псевдонимом Хренов. Вот поди потешался мужик, при отправке докладов в политбюро

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

[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

[mazzy]

Цитата:

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

При решении в лоб и достижении некоего кол-ва уровней - снесет без вопросов.

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

Цитата:

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

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

Расставил

[glibs]

Цитата:

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

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

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

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

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