Гибкая разработка и изменения базы данных [закрываются]

Для каждого обновления я был бы:

• развертывание сценариев отката вперед и отката,
• развертывание "сборки DB с нуля" сценарий,
• развертывание сценария миграции данных, и
• осуществление механизма, посредством чего код заблокирован к версии базы данных, т.е. тестирующий на значение, которое возвращает текущую версию DB, если существует несоответствие, системные залоги и блеют громко о несоответствии.

HTH

удачи,

Ограбить

В нашей Гибкой установке существует папка для изменений DB, сделанных как.SQL файлы. До сих пор у нас было изменение DB в каждой версии, и файл называют в честь версии приложения. Сценарий установки автоволшебно применяет все файлы изменения при обновлении сайтов.

У нас также есть полный дамп схемы ссылочного DB, это используется для новых установок, созданных нашим Административным средством DB.

Я знаю, что существуют инструменты, что справка автоматизирует этот процесс, такой как Красный Логический элемент, но вручную создание файла изменения SQL очень легко.

Идеально Вы вносите не повреждающиеся изменения, затем когда выпуск сделан, можно полностью удержать от использования старые части схемы. Это не легко и требует дисциплины. Это даже не всегда возможно.

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

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

Гибкая методология не отличается, чем другие методологии, в которых это к Вашему преимуществу для разработки базы данных впереди как можно больше, и необходимо стремиться изменить его менее часто, чем код. Для не высказывания Вы никогда не можете изменять его, но это является дорогостоящим, чтобы сделать так.

Миграции являются простым, но эффективным инструментом для отслеживания изменений схемы, как другие отметили. Причем понятие является сценариями операторов CREATE и ALTER для обновления от одного пересмотра схемы к следующему, сопровождаемому сценариями операторов ALTER и DROP для понижения тех же изменений. Ruby on Rails использует уровень абстракции базы данных сверху этого, чтобы помочь переключить бренды базы данных, но если только необходимо поддерживать один бренд, Вы могли бы просто использовать файлы SQL.

Существует высоко оцененная книга по этому предмету (хотя я еще не нашел время для покупки или чтения его), названный "Рефакторинг Баз данных: Эволюционное Проектирование баз данных" Scott Ambler