stydentik,

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

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

На практике, получается:
1. убрать весь Г-код. Особенно всяческие SELECT *. Выборки должны тащить ровно то что им необходимо. С этой целью была сделана прокладка в виде базового класса, через которую теперь идут все запросы к таблицам. Множественные разовые и "узкоспециальные" выборки были заменены на генератор выборок, формирующие запросы "как надо"... уже на этом этапе код стал и читаемее и проще и, как ни странно, шустрее. Да, транзакционность обновлений и втыкание проверок.

2. после п.1. можно готовить расширения БД вполне нормально прямо на рабочей версии. Новые поля - все равно ни на что не влияют. Новые таблицы - тем более. К таблицам можно добавить доп. поле - "старые данные" и проставить в нем признак. Оно уже ни на что не повлияет.

3. делается новый код. Фактически, с учетом п.1. - это расширения генератора запросов. по мере продвижения тут, новые поля и новые таблицы начинают заполняться данными большей частью "автоматически".

4. по необходимости - делаем перенос в новые таблицы "старых" данных... признак есть, перенос - не проблема.

5. удаляем всё, что уже не нужно.