Показать сообщение отдельно
Старый 01.01.2011, 21:28   #1  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Переход с Axapta 3.0 на AX 2009 - критика утилиты конвертации БД и скриптов обновления
Думаю, в ближайшее время для многих компаний будет актуален вопрос перехода с версии 3.0 на 2009-ю. Если у компании достаточно большая база, и компания не хочет переходить лишь со справочниками и начальными остатками, то возможность конвертации такой большой базы стандартными средствами в приемлемые сроки может стать серьезным препятствием: обычно простой приемлем в течение выходных (т.е. в районе 60-и часов, включая вечер пятницы и утро понедельника), в то время как стандартный способ конвертации базы представляется, мягко говоря, далеким от оптимального.
Что предлагается сделать при штатной конвертации базы:
  • перевести базу на левое выравнивание;
  • удалить из базы данные, которые не предполагается переносить, т.е. затраты времени на перенос которых не оправданы (всякие там логи, параметрические таблицы для обработки заказов/закупок и т.п);
  • с помощью отдельной утилиты создать слепок базы 3.0, подготовленный для AX 2009 (с данными, конвертированными в Unicode, с 64-битными полями под RecId, но со схемой от базы 3.0); утилита не разбирает, какие таблицы переносит, поэтому чтобы не переносить лишнее, нужен предыдущий шаг;
  • с помощью скриптов конвертации:
    • перенести часть данных из удаляемых полей в новые (например, из createdTime/modifiedTime - в createdDateTime/modifiedDateTime);
    • заполнить часть новых полей константами либо значениями других полей той же записи (например, новые поля с MST-суммами могут заполняться из полей с валютными суммами при условии совпадения валюты проводки и основной валюты компании);
    • перебить значения некоторых enum'ов на новые (т.е. было значение 200, стало 5);
    • ну и выполнить какие-то нетривиальные преобразования.
Мне лично непонятно, зачем нужно тратить столько драгоценного времени на тупое перелопачивание одних и тех же данных, если кучу перечисленных действий можно было бы выполнить в рамках одного этапа - создания слепка базы 3.0, подготовленного для AX 2009. Ведь можно было бы на лету:
  • переводить данные на левое выравнивание;
  • заполнять поля типа UtcDateTime из имеющихся старых пар полей типа date + time (а это в скриптах конвертации реализовано офигенски неэффективно);
  • перебивать значения enum'ов;
  • заполнять новые либо незаполненные старые поля, если их значения можно легко и просто вычислить из других полей записи либо вообще задать константами;
  • выбирать, какие таблицы не переливать вовсе;
  • фильтровать переливаемые таблицы, чтобы не переливать лишние данные (всякие там отмененные/закрытые и т.п. записи либо записи с датой ранее заданной);
  • и много чего еще...
При всем при этом за счет сокращения числа промежуточных "переделов" базы можно также сократить число создаваемых по ходу конвертации резервных копий, что даст дополнительный выигрыш во времени. В общем, отсюда вопрос: почему стандартная конвертация сделана так неэффективно? Я уже молчу про скрипты перебивки енумов, которые зачем-то запускаются в разрезе компаний вместо выполнения одного прямого SQL-запроса, но зачем же столько ненужных промежуточных действий?..
Кто как боролся с этими проблемами - из тех, кому уже приходилось участвовать в переходе на 2009-ю с конвертацией имеющейся базы? Если верить недавнему семинару, кто-то для части таблиц отключает поля createdDate/modifiedDate, чтобы сэкономить время на их преобразовании в createdDateTime/modifiedDateTime, но это, по-моему, не выход... Какие еще есть варианты?
За это сообщение автора поблагодарили: Logger (5).