16 и более полей в InventDim

[Ievgenii]

В Ах + SQL ограничение полей в индексе 16. В складских аналитиках есть 8 стандартных полей + поле компании. В российской локализации судя по постам mazzy есть еще поля (допустим еще 2-3), то есть уже 12-13, а так до 16 рукой подать.

Я так понимаю, что многие еще 1-3 добавляют, а некоторые наши партнеры еще +10 требуют.

Вопрос - сталкивались ли вы с ситуацией, когда количество полей inventDim переваливало за 16 и если да - то что вы делали?

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

Спрашиваю, потому что данный вопрос становиться все более и более актуальный с каждым новым релизом

Спасибо.

[TasmanianDevil]

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

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

Предлагаемая архитектура дает больший запас прочности к увеличению потребного кол-ва аналитических разрезов номенклатуры (7*Nгрупп по складской аналитике + 7*Mгрупп по номенклатурной аналитике - при увеличении кол-ва групп кол-во возможных аналитик растет в геометрической прогрессии), но при этом потребует упорядоченности в структуре учета.

Нашу битву с mazzy на эту тему можно в треде "Производительность и InventDim" поглядеть.

[S.Kuskov]

Ievgenii, а можно вас попросить прокомментировать вот это сообщение dax-lessons: Deactivating configuration key will not affect the table any more [Dynamica AX 2012].
На сколько я понял в AX2012 отключение конфигурационных ключей НЕ вызывает удаление соответствующих таблиц в БД.

Цитата:

Сообщение от S.Kuskov

А на отдельные поля таблиц это тоже распространяется?
Спрашиваю потому что как-то пришлось столкнутся с неприятным ограничением SQL Server'а на количество полей в индексе. Например для таблицы InventDim этот фактор легко может оказаться критичным если начать учитывать все поля существующие в таблице. Сейчас проблему можно решить если часть не используемых полей просто выключить конфигурационными ключами, а что делать в таком случае в AX2012?

[Pustik]

Цитата:

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

Я могу предположить что сделав индеск на таблице инвент дим не уникальным то систему это не поломает, ибо много где есть findCreate(), так что вроде должно работать.

Ой - Ой - Ой. Вы поосторожнее. Не дай бог Вам попасть в такую ситуацию, в которую попали мы:
Чья-то "умная" рука(догадываюсь, что этот индивидум из консалтинговой компании, которая когда-то у нас внедряла Управление запасами) к основному индексу в таблице InventDim добавила поле RecId. Таким образом этот индекс мнимо стал не уникальным. Заметили мы это очень и очень поздно. Таким образом у нас образовались одинаковые комбинации аналитик с разными InventDimId. И вот тут началась "веселая" жизнь. Вопросы пользователей о том почему нельзя списать, когда на складе есть. Почему система показывает, что на складе нет, когда я только что оприходовала и т.д. и т.п.. Поверьте мне чинилось это очень и очень сложно.

[Alexius]

В AX2009 EE SP1 RU7 12 штатных аналитик. Затык происходит не на InventDim, а на InventSumDeltaDim / Indexes / TTSItemCheckDimIdx, в нем присутствуют еще 3 поля, соответственно уже достигнут предел аналитик (12 + 3 + 1 = 16) и добавление новых возможно только при отключении имеющихся. Мы пока часть отключили конфигурационными ключами, а часть приняли за условно отключенную (поля всегда пустые), что делать если понадобятся новые аналитики пока не представляю.
Наиболее рационально, на мой взгляд, вообще отказаться от конструкции InventDim и перейти на аналог Dimensions. Единственный плюс InventDim мне кажется - это экономия места в БД, все остальное - минусы.

PS. Переводить контроль уникальности набора аналитик в InventDim на приложение считаю совершенно не правильным, но возможным как крайняя мера

[pitersky]

Цитата:

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

Разделеление InventDim - комбинации аналитик хранения и номенклатурных аналитик нечего мешать в одну кучу

вот с этим на все 100% согласен. как правило, номенклатурные аналитики не используются, а поля в InventDim занимают.
Например, можно сделать отдельный InventDim только для номенклатурных аналитик, а его InventDimId прописывать как одну аналитику в большом InventDim.

[fed]

Я с этим сталкивался. (Правда это не мой проект был, я там приходящий консультант ). Там просто сделали дополнительное поле (типа CombinedDim), которое при любой вставке заполняют комбинацией вида Dim1+'#'+dim2+'#'+dim3. И именно это поле засунуто в индекс вместо трех обычных полей. Правда это привело к некоторым (не критичным) проблемам производительности. Во первых - они там побоялись заменить в inventDim::findDim() старые поля на новое (то есть - в индексе комбинированное поле, а в select where - три некомбинированых). Из за этого чуток (думаю - процентов на 10) падает производительность поиска по таблице (на самом деле оставшихся 13 полей вполне хватает для нужной селективности), и заметно падает производительность кэширования (поскольку из кэша AOS вынимает данные только если в select where стоит комбинация всех полей из уникального индекса). Соответственно - любой вызов findOrCreate гарантировано ведет в передаче select к серверу базы данных. Я клиенту предлогал метод подправить, но они мне сказали что производительности пока хватает, сервер мощный, и от добра добра не ищут...

P.S. Но было бы лучше, если бы вы больно попинали группу MS SQL, чтобы в следующей версии они довели бы число поддерживаемых полей в индексе до 32

[Alexius]

Цитата:

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

P.S. Но было бы лучше, если бы вы больно попинали группу MS SQL, чтобы в следующей версии они довели бы число поддерживаемых полей в индексе до 32

И до кучи еще расширили ограничение в 900 байт, а то в юникоде в него легко можно упереться.

[Vadik]

Цитата:

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

И до кучи еще расширили ограничение в 900 байт, а то в юникоде в него легко можно упереться

Что-то вы люди не то индексируете по-моему
P.S. А с пожеланиями по SQL Server лучше сюда

[ice]

Цитата:

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

Что-то вы люди не то индексируете по-моему

ну в аксапте индексные поля обычно текстовые, а в качестве кода часто выступает не генерируемое выражение, а "реальное название", так что немудренно что индекс получается очень большим

[ppson]

есть проект где 23 складские аналитики

[George Nordic]

Часть сообщений выделена в тему: Необходимое количество номенклатурных аналитик

С Уважением,
Георгий

[donMigel]

Цитата:

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

Вопрос - сталкивались ли вы с ситуацией, когда количество полей inventDim переваливало за 16 и если да - то что вы делали?

Не сталкивались, соответственно, ничего не делали.

Но раз коллеги развернули полемику, то и я, с позволения, в ней поучаствую. Если принять как очевидность, что количество номенклатурных аналитик, то есть характеристик сущности объекта, стремится к бесконечности, ибо одних только органов чувств у человека 7 да ещё маркетинговые характеристики, а сколько комбинаций! То можно придти к выводу, что номенклатурные аналитики и складские аналитики разделять смысл есть. Такой шаг снимет немного критичность проблемы. И будет время для принятия другого решения, пока достигнется ограничение в 16 полей.
А дальше либо это ограничение принимать как должное, как то, что солнце светит днём и не светит ночью, либо менять ПО, то есть солнце
И ещё уже из своей практики,16 полей для именно складских аналитик вполне достаточно. Но это обсуждение из уже выделенной ветки.