Сохранение схем базы данных sql, синхронизированных между разработчиками

Question

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

Жаль только сказать, что это .net C# проект

Любые идеи?

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

• Добавить SQL Schema Generation в SVN
• Добавить Сценарии вставки данных в SVN
• Добавить Schema/Data отвалов в SVN

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

Я прочитал артикул несколько лет назад от Пола Грэма, о «Agile Database Development». У меня проблемы с поиском. Кажется, что все эти термины являются слишком универсальными, и моя память слишком размыта, чтобы приблизиться.

Я побежал acrossed http://code.google.com/p/migratordotnet/

Это по образцу Migrator Rails ActiveRecord (о которых говорилось ранее), но и направлена ​​на .net. Я не программист .net, но это похоже на то, что вы ищете.

Answer 8

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

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

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

Answer 9

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

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