Там, где я работаю, каждый разработчик (фактически каждая виртуальная машина разработки) имеет свою собственную базу данных (или, скорее, свою собственную схему в общем экземпляре Oracle). Наш рабочий процесс основан на полной перестройке. У нас нет никакой возможности модифицировать существующую базу данных - у нас есть только ядерная возможность сносить всю схему и строить с нуля.
У нас есть небольшой скрипт «отбросить все», который использует запросы к системным таблицам для идентификации каждого объекта в схеме, создает кучу SQL для их отбрасывания и запускает его. Затем у нас есть стек файлов DDL, полный операторов CREATE TABLE, затем у нас есть стек файлов XML, содержащих исходные данные для системы, которые загружаются средством загрузки. Все это проверено в системе контроля версий. Когда разработчик выполняет обновление из системы контроля версий, если он видит входящие изменения базы данных (DDL или данные), он запускает сценарий основной сборки, который запускает их для создания новой базы данных с нуля.
Хорошо, что это делает жизнь проще. Нам никогда не нужно беспокоиться о разнице, дельте, ALTER TABLE, обратимости и т. Д., Просто о DDL и данных. Нам никогда не нужно беспокоиться о сохранении состояния базы данных или поддержании ее в чистоте - вы можете вернуться в чистое состояние одним нажатием кнопки. Еще одной важной особенностью этого является то, что это упрощает настройку новой платформы - и это означает, что когда мы добавляем больше машин для разработки или когда нам нужно создать систему принятия или что-то еще, это легко. Я видел, как проекты проваливались, потому что они не могли создавать новые экземпляры из своих запутанных баз данных.
Главное, что плохо, это занимает некоторое время - в нашем случае, из-за особых удручающих деталей нашей системы, мучительно долгое время, но я думаю, что команда, которая действительно была на вершине своих инструментов, могла бы сделать полное перестроить так за 10 минут. Полчаса, если у вас много данных. Достаточно короткий, чтобы можно было делать несколько раз в течение рабочего дня, не убивая себя.
Проблема в том, что вы делаете с данными. У этого есть две стороны: данные, сгенерированные во время разработки, и оперативные данные.
Данные, сгенерированные во время разработки, на самом деле довольно просты. Люди, которые не работают по-нашему, по-видимому, имеют привычку создавать эти данные непосредственно в базе данных, и поэтому видят проблему в том, что они будут потеряны при перестроении. Решение простое: вы не создаете данные в базе данных, вы создаете их в сценариях загрузчика (в нашем случае это XML, но вы можете использовать SQL DML или CSV с инструментом импорта вашей базы данных или любым другим). Считайте, что скрипты загрузчика являются исходным кодом, а база данных - объектным кодом: скрипты представляют собой окончательную форму и являются тем, что вы редактируете вручную; база данных - это то, что сделано из них.
Живые данные жестче. В моей компании не было разработано ни одного процесса, который бы работал во всех случаях - я не знаю, просто не нашли ли мы волшебную пулю или ее нет. Один из наших проектов использует подход, который в реальном времени отличается от разработки, и что нет полной перестройки; скорее они разработали набор методов для определения дельт при создании новой версии и применения их вручную. Они выпускаются каждые несколько недель, так что часто это всего лишь пара дней работы для нескольких человек. Не много.
Проект, на котором я работаю, еще не запущен, но он заменяет существующую живую систему, поэтому у нас похожая проблема.Наш подход основан на миграции: вместо того, чтобы пытаться использовать существующую базу данных, мы переносим все данные из нее в нашу систему.Для этого мы написали довольно обширный инструмент, который запускает запросы к существующей базе данных (ее копия, а не текущая версия!), А затем записывает данные в виде сценариев загрузчика.Затем они включаются в процесс сборки, как и любые другие.Миграция выполняется по сценарию и выполняется каждую ночь как часть нашей ежедневной сборки.В этом случае усилия, необходимые для написания этого инструмента, были необходимы в любом случае, потому что наша база данных сильно отличается по структуре от старой;возможность повторяемых миграций одним нажатием кнопки предоставляется бесплатно.
Когда мы начнем работу, одним из наших вариантов будет адаптация этого процесса для перехода от старых версий нашей базы данных к новым.Нам придется писать совершенно новые запросы, но они должны быть очень простыми, потому что исходная база данных является нашей собственной, и отображение из нее в скрипты загрузчика, как вы можете себе представить, прямолинейно, даже как новая версияСистема отходит от живой версии.Это позволило бы нам продолжать работать в полной парадигме перестройки - нам все равно не нужно было бы беспокоиться об ALTER TABLE или о поддержании чистоты наших баз данных, даже когда мы выполняем обслуживание.Я понятия не имею, что будет думать об этой идее операционная команда!