27.03.2008, 10:19 | #21 |
Участник
|
Цитата:
Наваять что-то универсально-монстроидальное - "а клиент пусть сам решает". А стоимость настройки? А стоимость сопровождения? А стоимость доработок поверх этого "и так, и так"? |
|
27.03.2008, 10:33 | #22 |
Участник
|
Цитата:
Цитата:
Но вообще в планах на 6ую версию проскакивал отказ от InventDim и вообще такого подхода.
Т.к. при использовании подобного подхода клиентам перенести свои модификации на 6.0 будет не реально или весьма проблемно. |
|
27.03.2008, 10:59 | #23 |
Участник
|
Очень интересная дискуссия, давайте как- то зафиксируем промежуточные результаты?
1. Щас есть два решения для хранения аналитик - InventDim и Dimensions 2. Недостатки InventDim - требуется лишний джоин интересно, есть ли данные насколько такой джоин дорог в количественном отношении? - невозможность пострения составного индекса для поиска по полю таблицы и полю InventDim для запросов типа X++: select * from InventTrans where InventTrans.ItemID == _itemID join InventDim where InventTrans.InventDimID == InventDim.InventDimID && InventDim.InventLocationID == _inventLocationID Это мне кажется ограничение скорее аксапты - в SQL server, насколько я знаю, есть возможность строить индексы по функциям общего вида => мало что мешает строит индексы по полю связанной таблицы - требуется лазить в дополнительную таблицу для получения оттуда данных 3. Недостатки Dimensions - если объем InventDim существенно меньше объема inventTans, то inventTrans распухнет при переходе к схеме Dimensions (с другой стороны, есть менее постоянные аналитики, для которых это оправдано) - нетипизированность ( все значения должны быть одного размера) - это ограничение наложенное аксаптой так как нет типа "структура" а есть тип "массив" 4. недостатки перехода InventDim --> Dimensions - отвалятся модификации использующие существующую архитектуру Я все правильно понял или что-то упустил? С моей точки зрения недостатки inventDim в какой-то степени можно нивелировать развитием движка аксапты, SQL сервера или возможности использования второго первым... |
|
|
За это сообщение автора поблагодарили: mazzy (5). |
27.03.2008, 11:08 | #24 |
Участник
|
Вроде правильно.
Спасибо за резюме. Надо подумать. |
|
27.03.2008, 11:14 | #25 |
Участник
|
Коллеги, а как была релизована аналитика в XAL ?
В упомянутом блоге Sven ссылается на XAL. Плюс интересно сравнить с Oracle и SAP Кто в курсе как там реализованы аналитики ? |
|
27.03.2008, 11:17 | #26 |
Участник
|
Цитата:
Размера и цвета не было. Склад, Серийный номер, Партия, Паллета, Ячейка были в inventDim. ГТД локализаторы также затолкали в InventDim (в Аксапту решение было перенесено из XAL). По этому поводу сильно возмущался Pavel, насколько я помню. Насколько я помню, одно из преимуществ альтернативной локализации XAL, которое предлагал Pavel, это - другая реализация работы с ГТД. Цитата:
В Навижине InventDim'а точно нет, есть специализированные поля, специализированные таблицы и специализированные индексы для каждой аналитики. |
|
27.03.2008, 11:31 | #27 |
Участник
|
Цитата:
InventDim поддерживает аналитики не только строкового типа. Я так понимаю, это практически никто не использует, но, насколько я понмю, мы на каком-то проекте таки использовали |
|
27.03.2008, 11:41 | #28 |
Участник
|
Сейчас полазил по доке на SQL на предмет освежить сведения по индексам - что-то не нашел такой возможности ! Для такого вида запросов наилучшим решением были-бы индексированные вьюшки - они действительно дают большой прирост производительности.
|
|
27.03.2008, 12:15 | #29 |
Мрачный тип
|
В курсе, раздел "простейшие одноклеточные"
Я скорее всего не совсем внятно выразился, не добавление , а его следствие пугает - общее число уровней аналитики, используемых в проводках, возрастает более быстрыми темпами, чем максимальное число одновременно используемых уровней. Тип счета в общем журнале или группировка в профилях разноски ОС и номенклатуры - есть зло ? Может быть для работы ними с каждого типа счета/группировки создать отдельное поле ссылки согласно классике одноклеточного мира ? Мое предложение расширяет уже используемую технологию с единичной ссылки до массива ссылок. Цитата:
Где Вы его увидели Enum в коде и отказ от таблицы настроек складских моделей ? На MoprhX - не жалко, на Аксапту - иногда жалко Цитата:
Цитата:
Секьюрити на уровни аналитики складской ? Можно в студию пример бизнес-процесса, когда понадобится раздавать разный доступ на разные уровни ? В одном заказе один менеджер выбирает цвет, второй менеджер размер, а знать, что выбрал другой, им не позволительно ? Не представляю такой ситуации в принципе ... А что с RLS не так ? Запрос при lookup на таблицы-справочники разрезов складской аналитики как строился согласно Relations на InventDim так и будет строиться, RLS как отрабатывал - так должен отработать.Настраивать RLS для строк документа, имеющих ссылку на складскую аналитику, в зависимости от ее значений ? Не всегда подобное необходимо, хотя если припрет - да, сложнее станет, но отнюдь не смертельно. ItemId, поле-массив Enum'ов, поле-массив ссылок - пока в ограничения платформы не упрется. Такой вот , блин, enum. Цитата:
Вырабатывает дисциплинированность и внимательность. Симметрично. Особливо когда понимаю возможности платформы системы и сравниваю с тем, что и как на ней создано. P.S. Цитата:
Буду как один академик-атомщик на заре становления атомной отрасли, из-за секретности он был под псевдонимом Хренов. Вот поди потешался мужик, при отправке докладов в политбюро
__________________
Мы летаем, кружимся, нагоняем ужасы ... Последний раз редактировалось TasmanianDevil; 27.03.2008 в 12:38. Причина: знаки препинания и очепятки |
|
27.03.2008, 12:18 | #30 |
Участник
|
Вот это Creating Indexes on Computed Columns
Теоретически ничто не мешает сделать специфический вид Computed Column, для которого легко сообразит, что она часть приджоэниной таблицы и транслировать (хоть бы и на уровне аксапты) условие по таблице в условие по вычисляемому полю. Другое дело что проблему "селективных аналитик" это не решит - InventDim будет пухлым. Возможно стоит сделать, чтобы селективные были в типа Dimension, а неселективные - в InventDim. только надо предусмотреть некоторый путь перехода для модифицированного кода от текущей ситуации к этой новой. Тут такие мысли: 1. Найти такой код легко - он просто перестанет компилироваться 2. Для корректно написынных форм с редактированием InventDim можно, наверное, сделать автоматический конвертер 3. Для кода с InventDim надо как-то сделать, чтобы можно было легко преобразовывать старый код в новый и список рекомендаций - вот тут мне на ум ничего не приходит... |
|
27.03.2008, 12:21 | #31 |
Участник
|
Цитата:
inventTrans.SelectiveDims.SerialNo |
|
27.03.2008, 12:25 | #32 |
Участник
|
И вообще, должен придти fed и расставить все на свои места!
|
|
27.03.2008, 12:38 | #33 |
Участник
|
TasmanianDevil, я правильно понял, что одно и то же поле будет в таблице иметь разный смысл (и конуептцально тип) в зависимости от настроек конфигурации?
А как интересно будет выглядеть тогда запрос "выбрать все с данного слклада" X++: 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) |
|
27.03.2008, 13:05 | #34 |
Мрачный тип
|
Цитата:
Сообщение от belugin
TasmanianDevil, я правильно понял, что одно и то же поле будет в таблице иметь разный смысл (и конуептцально тип) в зависимости от настроек конфигурации?
А как интересно будет выглядеть тогда запрос "выбрать все с данного слклада" X++: 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) Общие для всех моделей разрезы аналитики использовать в едином для всех разрезе(порядок и уровень). Допустим общие у нас разрезы - это "склад" и "кладовщик", первым уровнем для всех моделей будет "склад", вторым - "кладовщик". Экзотику , специфичную для каждой конкретной модели опускать на нижние уровни. У обоих вариантов есть недостатки - но их можно считать это платой за универсальность
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
27.03.2008, 13:39 | #35 |
Moderator
|
В общем - в подробности я пока лезть не буду (времени нету), но по моему при подобной степени модификации Аксапты, дальнейшие затраты на поддержку и развитие системы, превысят стоимость ОЧЕНЬ крутого сервера БД. При нынешнем росте зарплат в России, инвестиции в железо в 95% случаев оказываются выгоднее, чем затраты на оптимизацию.
|
|
|
За это сообщение автора поблагодарили: mazzy (2). |
27.03.2008, 14:25 | #36 |
Участник
|
|
|
27.03.2008, 14:45 | #37 |
Участник
|
Цитата:
Сообщение от TasmanianDevil
В курсе, раздел "простейшие одноклеточные"
Я скорее всего не совсем внятно выразился, не добавление , а его следствие пугает - общее число уровней аналитики, используемых в проводках, возрастает более быстрыми темпами, чем максимальное число одновременно используемых уровней. Цитата:
Сообщение от TasmanianDevil
Тип счета в общем журнале или группировка в профилях разноски ОС и номенклатуры - есть зло ? Может быть для работы ними с каждого типа счета/группировки создать отдельное поле ссылки согласно классике одноклеточного мира ? Мое предложение расширяет уже используемую технологию с единичной ссылки до массива ссылок.
Может создадите новую ветку и выскажетесь подробно и с аругментами? Цитата:
Сообщение от TasmanianDevil
Enum не в коде, он в AOT, и использовать его предлагается как раз в таблице настроек моделей(массив на основе этого Enum), определяя какой уровень складской аналитики ссылается на какой справочник. В дальнейшем, в создаваемых строках документов, где есть привязка к складской аналитике, упомянутый массив из модели складской аналитики, соответствующей номенклатуре строки документа, скопируется в соответствующий массив в InventDim и, согласно прописанных Relations, определит поведение lookup при выборе на соответсвующем уровне аналитики.
Где Вы его увидели Enum в коде и отказ от таблицы настроек складских моделей ? схему данных можно? Цитата:
Сообщение от TasmanianDevil
Секьюрити на уровни аналитики складской ? Можно в студию пример бизнес-процесса, когда понадобится раздавать разный доступ на разные уровни ?
В одном заказе один менеджер выбирает цвет, второй менеджер размер, а знать, что выбрал другой, им не позволительно ? Не представляю такой ситуации в принципе ... Цитата:
Сообщение от TasmanianDevil
А что с RLS не так ? Запрос при lookup на таблицы-справочники разрезов складской аналитики как строился согласно Relations на InventDim так и будет строиться, RLS как отрабатывал - так должен отработать.Настраивать RLS для строк документа, имеющих ссылку на складскую аналитику, в зависимости от ее значений ? Не всегда подобное необходимо, хотя если припрет - да, сложнее станет, но отнюдь не смертельно.
Ничего не понимаю. Цитата:
Цитата:
|
|
27.03.2008, 14:47 | #38 |
Moderator
|
Да в общем - имелись в виду любые модификации, связанные со слишком глубоким изменением существующего подхода к работе со складскими проводками и складской аналитике Из любви к искусству обсуждать "как бы было правильно спроектировать Аксапту", мне жалко времени. Все равно - Аксапта такая какая она есть и ее достоинства являются продолжением ее недостатков. Практической ценности в такой дискуссии не очень много, потому что с точки зрения стоимости владения, подобные переработки явно проигрывают замене железа на более мощное или использованию трюков, связанных с тонкой настройкой БД (скажем тех же clustered indexed view в SQL Server или Index Cluster/Hash Cluster в Oracle).
Кстати - вот одна из моих любимых статей в jargon file: http://www.catb.org/~esr/jargon/html/B/brute-force.html |
|
|
За это сообщение автора поблагодарили: belugin (5), aidsua (1). |
27.03.2008, 14:47 | #39 |
Участник
|
Цитата:
Но этот механизм не даром слывет самым тормознутым в 1С. В общем, давайте схему данных Цитата:
Сообщение от fed
В общем - в подробности я пока лезть не буду (времени нету), но по моему при подобной степени модификации Аксапты, дальнейшие затраты на поддержку и развитие системы, превысят стоимость ОЧЕНЬ крутого сервера БД. При нынешнем росте зарплат в России, инвестиции в железо в 95% случаев оказываются выгоднее, чем затраты на оптимизацию.
|
|
27.03.2008, 16:16 | #40 |
Member
|
Цитата:
Сообщение от miklenew
...
Т.к. при использовании подобного подхода клиентам перенести свои модификации на 6.0 будет не реально или весьма проблемно. ... Он программировать будет с умом. И постарается много не писать. И писать правильно. А если делать не так, то любой переход на новую версию покажется чем-то фантастическим и несбыточным. Даже если не менять революционно аналитики.
__________________
С уважением, glibs® |
|
Теги |
axapta, faq, inventdim, производительность |
|
Похожие темы | ||||
Тема | Ответов | |||
dynamicsmatters: Performance and Inventdim PII | 17 | |||
dynamicsmatters: Dynamics AX Base Data Model Part II | 0 | |||
Dynamics AX Geek: #InventDimJoin | 0 |
|