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

[fed]

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

 To reduce the amount of data stored (disk space)
 To refactor parts of the table to avoid redundant data and the inherent risk of inconsistent data

Надо было всего-то разделить таблицу inventTrans на 5 основных таблиц и порядка 25 вспомогательных (я так полaгаю - по числу подкласов, унаследованных от inventMovement).
Это именно то, что было надо каждому разработчику. Сэкономить дисковое пространство (которое нонче копейки стоит) и избежать "inherent risk of inconsistent data", путем создания тучи сложно связанных таблиц. Передай большое человеческое спасибо разработчикам модуля логистики.
Спроси - слышали ли они термин "over-normalization" ?

[Ievgenii]

Цитата:

Передай большое человеческое спасибо разработчикам модуля логистики

Эта фраза как тут говорять - make my day Обязательно передам.

Цитата:

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

Это понятно - в общем с первого взгляда новая версия от всех до нее версий сильно отличаються. С другой стороны не так страшен черт как его рисуют . В этом случаи инвент транс* normalized по сравнению с ax2009, что дает улутшения по производительности в целом + много плюсов для архитекруты системы (не говоря уже какое количество багов было пофикшено по ходу).

Эти доки - только самые первые, я думаю далеко не все моменты были освещены, по этому не стоит спешить с выводами.

Все что не делаеться - делаться только на благо (или покрайней мере с найлутшими намериниями).

Вообще-то удобство разработки конечно важно, но не является первоочередной целью.
По мне так там довольно всё просто. Наверное, вы слишком консервативны.

[sukhanchik]

Цитата:

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

В этом случаи инвент транс* normalized по сравнению с ax2009, что дает улутшения по производительности в целом

Это с каких это пор нормализация давала улучшения в производительности? Наоборот - выборка из одной денормализованной таблицы гораздо быстрее, чем из пачки мелких.
Другое дело, что в АХ исторически сложилось писать select * from таблица, т.е. выбирать все поля, а не поштучно. Это конечно удобно для разработчика, но с т.з. быстродействия все же лучше в коде указать список полей для выборки, нежели "пилить" таблицу.
Посмотрим конечно - но уже сейчас на форуме то и дело проскакивают сообщения об общей тормознутости АХ 2009 после АХ 4.0 и тем более 3.0.
Уже страшно предположить что будет в АХ 2012 на реальных данных.

Цитата:

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

Все что не делаеться - делаться только на благо (или покрайней мере с найлутшими намериниями).

"Благими намерениями дорога в ад вымощена" (с). Все дела в мире делаются исключительно с благими намерениями. Жизнь покажет - насколько такие архитектурные решения были оправданы.

Особенно мне понравился тот факт (это из другого документа), что хотя в АХ 2012 и не отказались от RLS - от него планируется отказаться в будущих версиях. Оно и понятно - отчеты на SSRS тяжело строить с проверкой всех прав. Но .... это ж ключевая технология - как от нее отказываться?

[imir]

Цитата:

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

Но .... это ж ключевая технология - как от нее отказываться?

А зачем RLS, когда можно создать 100500 таблиц клиентов и товаров.
Dax 12 - почувствуй нашу любовь %)

[mifi]

Цитата:

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

Это с каких это пор нормализация давала улучшения в производительности? Наоборот - выборка из одной денормализованной таблицы гораздо быстрее, чем из пачки мелких.
Другое дело, что в АХ исторически сложилось писать select * from таблица, т.е. выбирать все поля, а не поштучно. Это конечно удобно для разработчика, но с т.з. быстродействия все же лучше в коде указать список полей для выборки, нежели "пилить" таблицу.
Посмотрим конечно - но уже сейчас на форуме то и дело проскакивают сообщения об общей тормознутости АХ 2009 после АХ 4.0 и тем более 3.0.
Уже страшно предположить что будет в АХ 2012 на реальных данных.



"Благими намерениями дорога в ад вымощена" (с). Все дела в мире делаются исключительно с благими намерениями. Жизнь покажет - насколько такие архитектурные решения были оправданы.

Особенно мне понравился тот факт (это из другого документа), что хотя в АХ 2012 и не отказались от RLS - от него планируется отказаться в будущих версиях. Оно и понятно - отчеты на SSRS тяжело строить с проверкой всех прав. Но .... это ж ключевая технология - как от нее отказываться?

Поскольку SSRS отчеты уже построили в ax 2012, то они здесь роли не играют. Если пользоваться стандартными средствами для построения SSRS отчетов, то все должно быть хорошо с RLS
Вместо RLS предлагается Extensible Data Security Framework (XDS), который, в общем, похож на RLS по принципу работы, но требует модификации соответствующих Policy в AOT

[sukhanchik]

Спасибо за информацию. А XDS - это технология, реализованная внутри АХ или СУБД?

[oip]

Так есть же дока по XDS: http://www.microsoft.com/downloads/e...ownload+Center)

[fed]

Возвращаясь к вопросу нормализации данных, я для себя выработал следующий простой критерий: Назначение всех неслужебных таблиц должно быть объяснимо в терминах специалистов предметной области. Типа: CustInvoiceJour - шапки накладных, CustInvoiceTrans - строки накладных, CustTrans - субконто проводок по поставщику, CustSettlement - данные о сопоставлениях (закрытии друг на друга) платежей и оплат.
Боюсь что "эта ваша" схема разложения складских проводок не в состоянии преодолеть этот простой критерий. А ведь все это придется объяснять не только разработчикам (которые, возможно, когда-то читали про нормальные формы) но и консультантам и пользователям (которые про них, скорее всего не читали).

Ну а насчет консерватизма: Каждый раз когда я вижу какое-то изменение в програмном продукте, я, совершенно точно, знаю что это приведет к дополнительным затратам для пользователя програмного продукта (по крайней мере чтобы научиться). Поэтому, в таких случаях, мне хочется понять, что же позитивного принесет пользователю (в широком смысле - от манагера проекта до бабушки-эндюзера) принесет это изменение. Боюсь что озвученных преимуществ недостаточно чтобы оправдать подобное изменение. К слову сказать, как уже было замечено sukhanchik'ом, высокая степень нормализации, несет заметное снижение производительности. А копеечный выигрыш в размере записей будет с лихвой перекрыт затратами на поддержание табличных структур данных для этих 25-30 таблиц.


Ну и наконец - по поводу документации, которая ждет нас в будущем. Я же видел документацию по версиям 4/2009. Обычно там перечислены галочки, а потом высосан из пальца жизненный пример:"Джейн работает рисовальщиком красных линий в Contoso. Заказчик просит ее нарисовать три красных линии. Джейн открывает модуль рисования красных линий и выбирает пункт меню Нарисовать Красные линии. В появившемся окне, она вводит число красных линий и нажимает Enter". И ко всему этому - штук 10 скриншотов. В общем - на практике быстрее в коде посмотреть, чем продираться через напластования банальшины и пересказа меток.

[mifi]

Цитата:

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

Спасибо за информацию. А XDS - это технология, реализованная внутри АХ или СУБД?

Ссылку на доку уже привели - если вкратце, то поскольку все security сделали декларативным (проще говоря, вытащили в AOT), то в первом приближении XDS можно также рассматривать - привязка ограничивающего query к наборе таблиц. Все со стороны AX, как и раньше

[fed]

Цитата:

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

Другое дело, что в АХ исторически сложилось писать select * from таблица, т.е. выбирать все поля, а не поштучно. Это конечно удобно для разработчика, но с т.з. быстродействия все же лучше в коде указать список полей для выборки, нежели "пилить" таблицу.

Хотя это, вероятно, офтопик дла данного раздела, но на самом деле, в большинстве случаев, разницы никакой нету. Все равно читается вся запись из БД и оттуда вынимаются все данные (даже если в запросе перечислена всего одна колонка). Единственные два исключения - покрывающие индексы и clustered views (которые, по моему, в 2012 не поддерживаются). Если у тебя есть, индекс по custAccount+salesId, то запрос select salesId from table where custAccount='blah' будет обрабатываться только чтением из индекса, в то время как запрос select * from table where custAccount='blah', будет приводить к чтению из индекса и из самой таблицы (ну или кластерного индекса если он есть).

[mifi]

Цитата:

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

Хотя это, вероятно, офтопик дла данного раздела, но на самом деле, в большинстве случаев, разницы никакой нету. Все равно читается вся запись из БД и оттуда вынимаются все данные (даже если в запросе перечислена всего одна колонка). Единственные два исключения - покрывающие индексы и clustered views (которые, по моему, в 2012 не поддерживаются). Если у тебя есть, индекс по custAccount+salesId, то запрос select salesId from table where custAccount='blah' будет обрабатываться только чтением из индекса, в то время как запрос select * from table where custAccount='blah', будет приводить к чтению из индекса и из самой таблицы (ну или кластерного индекса если он есть).

Действительно немного оффтопик, но это как минимум неверно для BLOB полей и может приводить к очень интересным результатам - как раньше, когда лого компании хранилось в CompanyInfo.

[EVGL]

Цитата:

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

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

 To reduce the amount of data stored (disk space)
 To refactor parts of the table to avoid redundant data and the inherent risk of inconsistent data

Надо было всего-то разделить таблицу inventTrans на 5 основных таблиц и порядка 25 вспомогательных (я так полaгаю - по числу подкласов, унаследованных от inventMovement).
Это именно то, что было надо каждому разработчику. Сэкономить дисковое пространство (которое нонче копейки стоит) и избежать "inherent risk of inconsistent data", путем создания тучи сложно связанных таблиц. Передай большое человеческое спасибо разработчикам модуля логистики.
Спроси - слышали ли они термин "over-normalization" ?

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

Хотя настоящие тормоза в логистике в Аксапте начинаются на частых запросах к InventSum join InventDim, а не к InventTrans.

[mifi]

Цитата:

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

Возвращаясь к вопросу нормализации данных, я для себя выработал следующий простой критерий: Назначение всех неслужебных таблиц должно быть объяснимо в терминах специалистов предметной области. Типа: CustInvoiceJour - шапки накладных, CustInvoiceTrans - строки накладных, CustTrans - субконто проводок по поставщику, CustSettlement - данные о сопоставлениях (закрытии друг на друга) платежей и оплат.
Боюсь что "эта ваша" схема разложения складских проводок не в состоянии преодолеть этот простой критерий. А ведь все это придется объяснять не только разработчикам (которые, возможно, когда-то читали про нормальные формы) но и консультантам и пользователям (которые про них, скорее всего не читали).

Ну а насчет консерватизма: Каждый раз когда я вижу какое-то изменение в програмном продукте, я, совершенно точно, знаю что это приведет к дополнительным затратам для пользователя програмного продукта (по крайней мере чтобы научиться). Поэтому, в таких случаях, мне хочется понять, что же позитивного принесет пользователю (в широком смысле - от манагера проекта до бабушки-эндюзера) принесет это изменение. Боюсь что озвученных преимуществ недостаточно чтобы оправдать подобное изменение. К слову сказать, как уже было замечено sukhanchik'ом, высокая степень нормализации, несет заметное снижение производительности. А копеечный выигрыш в размере записей будет с лихвой перекрыт затратами на поддержание табличных структур данных для этих 25-30 таблиц.


Ну и наконец - по поводу документации, которая ждет нас в будущем. Я же видел документацию по версиям 4/2009. Обычно там перечислены галочки, а потом высосан из пальца жизненный пример:"Джейн работает рисовальщиком красных линий в Contoso. Заказчик просит ее нарисовать три красных линии. Джейн открывает модуль рисования красных линий и выбирает пункт меню Нарисовать Красные линии. В появившемся окне, она вводит число красных линий и нажимает Enter". И ко всему этому - штук 10 скриншотов. В общем - на практике быстрее в коде посмотреть, чем продираться через напластования банальшины и пересказа меток.

В общем, бабушке-ендюзеру в данном релизе, по крайней мере, переучиваться особо не придется. Все, что ее могло раньше интересовать, осталось в старом InventTrans на 99 %. Разработчики - это другой вопрос, хотя и здесь изменение скорее техническое, а не идеологическое, так что сильно переучиваться именно здесь не придется

[fed]

Цитата:

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

Действительно немного оффтопик, но это как минимум неверно для BLOB полей и может приводить к очень интересным результатам - как раньше, когда лого компании хранилось в CompanyInfo.

Угу - забыл перечислить. Кстати - гораздо более жизненный пример - таблица reqLog. У меня на проекте форма reqLog открывалась порядка 30 минут при примерно 60 записях.

[Logger]

Цитата:

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

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

Хотя настоящие тормоза в логистике в Аксапте начинаются на частых запросах к InventSum join InventDim, а не к InventTrans.

Да при чем здесь кеш, если обсуждаем транзакционные таблицы ? Он там ускорить ничего не может. Скорее просадит аос по производительности. Миллионы записей же.

Про InventSum полностью согласен. На нашем проекте сделали денормализацию по складу - очень сильно ускорилось все. Использование памяти сервером БД тоже уменьшилось.

[Alexius]

Почитал про изменения в InventTrans и возникло несколько вопросиков, не обязательно к сотрудникам МС, может я сам что-то упустил:
1. Почему название поля InventTransOrigin с названием таблицы ? Логичнее кажется добавить для единообразия суффикс Id
2. Есть ли таблица InventTransOrigin и по каким полям она связывается с InventTrans и InventTransOriginSalesLine (и т.д.) или ее поля перекочевали в InventTransOriginSalesLine (и т.д.), что согласуется с примером запроса, но не структурой БД ?
3. Поле InventTrans.InventTransOrigin на сколько я понял из запроса сделано уникально для идентификации записи InventTrans?
4. Зачем поле OriginatingTable в таблицах InventTransOriginSalesLine (и т.д.) ?
5. Что хранит поле InventTransOrigin.ItemInventDim ?

[fed]

Цитата:

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

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

Если в таблице много пустых полей или полей с повторяющимися значениями, то можно гораздо сильнее и, главное, проще сэкономить место на диске и в кэше SQL-сервера, просто включив страничную комрессию для индексов. Правда при этом нагрузка на CPU сиквела возрастет и чуток производительность операций записи снизиться. Но мне кажется, джойн 3-4 таблиц в плане роста нагрузки на сервер и падения производительности по чтению, легко перекроет вариант компрессии...

[AndyD]

Цитата:

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

Хотя это, вероятно, офтопик дла данного раздела, но на самом деле, в большинстве случаев, разницы никакой нету. Все равно читается вся запись из БД и оттуда вынимаются все данные (даже если в запросе перечислена всего одна колонка). Единственные два исключения - покрывающие индексы и clustered views (которые, по моему, в 2012 не поддерживаются). Если у тебя есть, индекс по custAccount+salesId, то запрос select salesId from table where custAccount='blah' будет обрабатываться только чтением из индекса, в то время как запрос select * from table where custAccount='blah', будет приводить к чтению из индекса и из самой таблицы (ну или кластерного индекса если он есть).

Ну, чтение из файла - это же не весь цикл получения данных по запросу.
При большом размере записи будет за один раз меньше кол-во переданных на клиент данных
Простой запрос select * from InventTable на моих данные в два с половиной - три раза медленнее, чем select itemId from InventTable

[Alexius]

Цитата:

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

Не согласен. На мой обывательский взгляд, чем меньше таблица - тем больше из нее поместится в кэш.

Для MS SQL не совсем так. Сервер стремится кэшировать наиболее часто используемые данные и далеко не обязательно это должна быть целиком вся таблица. При построении структуры БД желательно помочь ему в этом, для этого мне кажется лучше было бы:
1. Объединить даты в одно поле
2. Объединить статусы прихода и расхода и выстроить их в порядке возрастания
3. Ввести уникальный ключ для InventTrans (пeсть и в связке с InventTransId)
4. Данные по накладным (отгрузочные, отборочные, финансовые) выделить в отдельную таблицу и при обработке последующей накладной добавлять строно запись по предыдущей.

Цитата:

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

, а Кроме того, в большинстве случаев в запросах к InventTrans поля InventRef и прочие не используются. В этом плане решение перебросить их в другую таблицу кажется логичным.

А как же банальная формочка просмотра проводок, если в нее попадает несколько сотен записей, то скорость работы с объединенными табличками скорее всего будет близка к скорости работы с одной, но если туда будут попадать тысячи записей, то накладные расходы сервера на объединение будут ощутимыми.