Синхронизация баз данных разработки в нескольких средах

Почему бы вам не сохранить в дополнение к сценарию CREATE базы данных сценарий данных по умолчанию или образец данных?

Это подход, который мы использовали для инкрементных версий приложения, которое мы поддерживаем более 2 лет, и он работает очень хорошо. Наличие сценария данных по умолчанию также позволяет вашим QA-тестерам воссоздавать ошибки, используя данные, которые у вас тоже есть?

Вы также можете взглянуть на вопрос, который я опубликовал некоторое время назад:

Лучший инструмент для автоматического создания сценариев изменения SQL

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

• Проекты баз данных в Visual Studio .NET
• Схема данных - как должны быть внесены изменения
• Находится ли ваша база данных под контролем версий?
• Поставьте свою базу данных под контроль версий
• Также ищите веб-трансляцию MSDN: Visual Studio 2005 Team Edition для специалистов по базам данных (часть 4 из 4): источник схемы и контроль версий

Однако, с учетом всего сказанного, если вы не думаете, что достаточно привержены реализации какого-либо типа управления версиями (ручного или полуавтоматического), то я НАСТОЯТЕЛЬНО рекомендую вам проверить следующее:

• Сравнение SQL Red Gate
• Сравнение данных SQL Red Gate

Святая корова! Поговорим об облегчении жизни! У меня был проект, который ускользнул от меня, и несколько человек вносили изменения в схему, и мне приходилось синхронизировать несколько сред. Было тривиально указать продукты Red Gate на две базы данных и увидеть различия, а затем синхронизировать их.

Вы можете хранить резервную копию (файл .bak) своей базы данных, а не файлы .MDF и .LDF.
Вы можете легко восстановить свою базу данных, используя следующий скрипт:

use master
go

if exists (select * from master.dbo.sysdatabases where name = 'your_db')
begin
    alter database your_db set SINGLE_USER with rollback IMMEDIATE
    drop database your_db
end

restore database your_db
from disk = 'path\to\your\bak\file'
with move 'Name of dat file' to 'path\to\mdf\file',
     move 'Name of log file'  to 'path\to\ldf\file'
go

Вы можете поместить вышеупомянутый скрипт в текстовый файл restore.sql и вызвать его из командного файла, используя следующую команду:

osql -E -i restore.sql

Таким образом, вы можете создать файл сценария для автоматизации всего процесса:

• Получите последнюю резервную копию базы данных из репозитория SVN или любого подходящего хранилища
• Восстановить текущую базу данных с помощью файла bak

Мы используем комбинацию из резервных копий из более высоких сред.
А также использование ApexSql для обработки первоначальной настройки схемы.
Недавно использовались Subsonic миграции, как закодированные, контролируемые источником, проходящие через CI способ для получения change scripts, есть также проект "tarantino", разработанный хедспринг из Техаса.

Большинство из этих подходов, особенно последний, безопасно использовать поверх большинства тестовых данных. Мне особенно нравятся автоматизированные последние 2, потому что я могу внести изменения, и в следующий раз, когда кто-то получит последнюю версию, они просто запустят «средство обновления», и они будут переведены на последнюю версию.