dynamicsmatters: Performance and InventDim

[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]

вторая часть
dynamicsmatters: Performance and Inventdim PII

[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. Не смотрите: Настройте ключи безопасности

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

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

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