Как вы работаете с изменениями схемы базы данных в команде разработчиков?

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

По крайней мере, у вас должны быть сценарии всех объектов в базе данных (таблицы, хранимые процедуры и т. Д.) Под контролем версий.

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

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

Ночная сборка приложения включала сборку базы данных (SQL Server). База данных построена на сервере Test DB. Затем у каждого разработчика был пакет DTS (это было некоторое время назад, и я уверен, что они перешли на пакеты SSIS), чтобы загрузить эту ночную сборку БД в свою локальную среду БД.

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

В моей работе мы имеем дело с довольно большими базами данных, создание которых требует много времени, поэтому для нас начинать с нуля с новой БД не идеально. Как и у Харпера, у нас есть DDL в SVN. Кроме того, мы храним номер версии в таблице базы данных. Каждая регистрация, которая изменяет БД, должна сопровождаться сценарием, который:

1. Обновит схему базы данных и соответствующим образом изменит любые существующие данные, а также
2. Обновит номер версии в базе.

Кроме того, мы нумеруем сценарии и версии базы данных таким образом, чтобы сценарий, который мы написали, знал, как выполнить дальнейшее обновление по ветке или от старой ветки к более новой без какого-либо ввода со стороны разработчика (кроме имени базы данных и каталога для сценарии обновления).

Таким образом, если у меня есть копия БД клиента объемом 4 ГБ, которая относится к версии годичной давности, и я хочу проверить, как их данные будут работать с версией, которую мы вырезали вчера, я могу просто запустить наш скрипт и позволить ему скорее выполнять обновления. чем необходимость начинать с нуля и повторять каждую операцию INSERT, UPDATE и DELETE, выполняемую с момента создания базы данных.

У нас есть не-SQL описание схемы базы данных. Когда приложение запускается, оно сравнивает желаемую схему базы данных с фактической схемой базы данных и выполняет все инструкции ADD TABLE, ADD COLUMN, ADD INDEX и т. Д., Которые ему необходимы, чтобы база данных выглядела правильно.

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

Я бы обязательно сохранил схему базы данных в исходном коде.

В моей текущей работе каждый раз, когда происходит изменение схемы, мы пишем SQL для изменения (alter table xyz add column ...) и помещаем его в SVN. Затем разработчики могут обновить тестовые базы данных, запустив этот скрипт. Это довольно коряво, но работает.

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

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