синхронизация схем базы данных sql между разработчиками

Question

Мы небольшая команда разработчиков (около 5 человек), занимающаяся разработкой проектов из разных мест. Мы используем SVN как репо.
Самая большая проблема, с которой мы сталкиваемся сейчас, заключается в том, что наша схема БД полностью не синхронизирована между всеми нами. У меня есть следующие варианты: 1. Отработать «центральную» БД. Это плохая идея и, скорее всего, не произойдет 2. Попросите разработчика «привратника», который будет поддерживать версию БД, и пусть каждый разработчик будет держать их в курсе изменений. 3. Заставьте каждого разработчика проверить свои изменения в скрипте изменения БД. Это может очень быстро запутаться.

Извините, просто упомяну, что это проект .net c #

Есть идеи?

Answer 1

У нас была та же проблема в проекте, в котором я сейчас работаю. Мы приняли Тарантино в качестве решения, которое работает на удивление хорошо. Каждый разработчик работает против локальной базы данных. Когда разработчику необходимо внести изменения в схему, он создает сценарий и регистрирует его.

Тарантино отслеживает, какие сценарии уже запущены каждым разработчиком в своей локальной базе данных, и применяет новые сценарии. Поэтому, если разработчик A вносит изменения и проверяет сценарий SQL, разработчик B получит это изменение, когда получит последние файлы из системы контроля версий. Когда разработчик B запускает Tarantino локально, будут применяться только самые последние сценарии.

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

Answer 2

MS немного отстает в том, что у нее пока нет стандартного решения, но ваш вариант №3 (изменение сценариев) - это путь, которым можно воспользоваться в наши дни. Большинство других современных основных языков используют форму этого в настоящее время в различных вариантах. например Ознакомьтесь с миграциями Rails.

В этом посте обсуждается множество доступных сторонних решений .NET. По моему опыту, migratordotnet является отличным выбором. Для более подробного изучения проблемы, прочитайте статью Мартина Фаулера на эту тему.

Answer 3

Почему работа на том же сервере баз данных снова будет плохой идеей? Потому что все разработчики вносят изменения, которые могут навредить другим? Если это так, я бы попросил одного человека заняться изменениями схемы и использовать VPN для входа в сеть, где есть сервер базы данных. Я сейчас в той же лодке, только что подобрал маршрутизатор Cisco, чтобы удовлетворить мои потребности в VPN по дешевке (<100 долларов). </p>

Answer 4

Несколько лет назад я прочитал статью Пола Грэма о гибкой разработке баз данных. У меня проблемы с поиском в Google, хотя. Кажется, что все эти термины слишком общие, и моя память слишком размыта, чтобы приблизиться.

Я бегал в акроссе http://code.google.com/p/migratordotnet/

Он смоделирован на миграторе Rails ActiveRecord (упомянутом ранее), но нацелен на .net. Я не программист .net, но это звучит как то, что вы ищете.

Answer 5

Это сложная проблема. Мы решили эту проблему путем пересмотра sql, используемого для генерации схемы (автоматически сгенерированной из Enterprise Architect). У нас были огромные проблемы, когда люди не обновляли свои схемы базы данных, потому что чувствовали, что воссоздание набора данных, содержащего достоверные данные тестирования, заняло слишком много времени.

Наше решение было:

• Добавление генерации схемы SQL в SVN
• Добавление сценариев вставки данных в SVN
• Добавление схемы / дампов данных в SVN

Мы использовали Hudson для настройки автоматической сборки базы данных, которая проверяла бы изменения в ревизии. Он автоматически воссоздает схему, вставляет все данные, экспортирует файл дампа и затем фиксирует файл дампа в SVN.

По сути, все сводилось к запуску импорта базы данных, который занял около 20 секунд. Если вы быстро создадите базу данных, у разработчиков не возникнет проблем с ее частым выполнением.

Answer 6

Эта проблема больше не встречается. Каждая команда должна задать этот вопрос в какой-то момент. Я сделал общий подход к БД и отдельный подход к БД. Команда всегда возвращалась к общей базе данных. Проще поддерживать, и все должны синхронизироваться рано, часто. Это не отменяет необходимости сохранять изменения и определения схемы в управлении версиями. Вам необходим повторяемый процесс обновления ваших тестовых, промежуточных и производственных сред. Чистых миграций SQL не всегда достаточно, но иногда вам нужно использовать собственные объекты для генерации данных или принятия решений. Лучшая система, которую я когда-либо видел (напоминает системы, которые я сам собрал в perl, php и Java, но улучшил пару моментов) - это система миграции Ruby on Rails. Проверьте это и сделайте что-нибудь подобное.

Answer 7

Я также работаю в небольшой команде, и сейчас у нас есть схема SQL и сценарии вставки данных, которые были добавлены в хранилище, как и наш код.

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

Answer 8

Если вы не используете продукты Team Edition для Visual Studio, тогда я бы выбрал вариант 3. Иметь сценарий sql под контролем исходного кода.

Синхронизация их локальных баз данных ничем не отличается от необходимости работы с последним исходным кодом.

Если вы используете продукты Team, то начните использовать редакцию базы данных (поставляется с Developer Edition) для управления базой данных под контролем исходного кода

Answer 9

Рассматривали ли вы возможность использования Visual Studio Team Database Edition? Он позволяет вам поместить всю исходную базу данных в систему контроля версий, и каждый разработчик может работать над своими собственными изменениями, а затем, как только они их зарегистрируют, другие разработчики могут легко развернуть эти изменения в своей собственной рабочей копии.

Не уверен, что есть плагин SVN, который будет работать с поставщиком MSSCCI - но я думаю, что для этого должно быть что-то.