Как вы подходите к управлению версиями базы данных при выполнении регулярных сборок?
У меня есть проект веб-приложения, который работает с довольно большой базой данных (более 5 ГБ). Данные в базе данных разбиты по проектам. Каждый проект занимает приблизительно 1 ГБ, и это минимальный набор для работы приложения (мы выполняем некоторые математические вычисления, которые распространяются по этому набору данных, и удаление части набора данных не вариант).
В рамках ежедневной сборки мы также внедряем наше приложение в тестовую среду. Для этого сборщик запускает специальную утилиту обновления БД, которая обновляет текущую БД до соответствующей версии. Но у нас также есть требование сохранять все ежедневные сборки, чтобы команда QA могла "вернуться назад во времени" и сравнить результаты расчетов для разных сборок. Как бы мы ни старались иметь обратно совместимую схему данных, иногда это очень сложно и отнимает много времени. Итак, отсюда вопрос:
Какой подход к управлению версиями базы данных вы бы использовали, если бы у вас было требование поддерживать и обновлять предыдущие ежедневные сборки и вам необходимо управлять большой базой данных при выполнении ежедневных сборок?
Мы используем SQL Server 2005 и ColdFusion с некоторым Java на внешнем интерфейсе, если это имеет какое-то значение.
1 ответ
Я бы предложил прочитать список Леона Бамбрика под названием " 11 инструментов для управления версиями баз данных".
И я бы добавил Visual Studio для специалистов по базам данных в список, который можно найти здесь
Также у Джеффа Этвуда есть хороший пост в блоге на эту тему со ссылками на некоторые материалы для чтения.