Показать сообщение отдельно
Старый 02.01.2011, 10:22   #2  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
  • перевести базу на левое выравнивание;
  • удалить из базы данные, которые не предполагается переносить, т.е. затраты времени на перенос которых не оправданы (всякие там логи, параметрические таблицы для обработки заказов/закупок и т.п);
Ничего же не мешает выполнить это заранее, а не в день Ч, правда ?
Цитата:
Ведь можно было бы на лету..
Теоретически ничего не мешает построить гораздо более эффективные запросы для обновления конкретной таблицы "на лету" в конкретного экземпляре приложения. Проблема в том, что
  • над скриптами обновления как собственно и над отдельными модулями работают назависимые команды и люди
  • отлаживать несколько простых скриптов им проще чем универсальный мегаскрипт (или получаем на выходе письмо дяди Федора)
  • скрипты должны работать (или не работать) в зависимости от состояния конфигурационных ключей
  • при апгрейде все равно где-то надо по каждой записи запускать бизнес-логику на X++ (те же расчеты AmountMST сумм и более сложную) зависящую от тех же enum-ов
Так что мегаскрипт тут не помощник
Что касается тормознутости отдельных скриптов, это частично компенсируется тем, что можно поиграть с количеством AOS-ов и параллельно выполняемых батчей
Цитата:
Если верить недавнему семинару, кто-то для части таблиц отключает поля createdDate/modifiedDate, чтобы сэкономить время на их преобразовании в createdDateTime/modifiedDateTime, но это, по-моему, не выход
Это один из выходов, кстати не самый плохой

Цитата:
Думаю, в ближайшее время для многих компаний будет актуален вопрос перехода с версии 3.0 на 2009-ю
Или уже на 6.0 ?
__________________
-ТСЯ или -ТЬСЯ ?