Управление миграцией БД: сценарии против инструментов

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

У нас есть два варианта в таблице, как управлять эволюция баз данных с течением времени:

• Какой-то инструмент. В настоящее время мы используем проекты баз данных Visual Studio, которые содержат текущее определение схемы, и смотрим на справочную базу данных для создания сценария сравнения. Затем мы используем этот сценарий сравнения, чтобы обновить справочную базу данных.
• Используйте сценарии версий для создания базы данных из базовой линии. Скрипты вручную помещаются в систему контроля версий. Любая миграция данных для перемещения данных из старых столбцов / таблиц в новые будет частью этих сценариев. Где-то в БД будет записана версия, и при обновлении будут выполняться все сценарии между версией БД и текущей версией.

Второй вариант, кажется, широко используется, и я нашел здесь подробное обсуждение: http: / /odetocode.com/blogs/scott/archive/2008/01/31/versioning-databases-the-baseline.aspx

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

Это делает идею запуска версионных сценариев привлекательной, потому что мы используем одни и те же сценарии во всех средах,и нет никакой специальной работы при развертывании (например, ручное восстановление продукта в справочную БД). Но, учитывая, что у нас такая небольшая ситуация с БД, я чувствую, что мы вряд ли можем быть трудным случаем для инструментов БД. Нам нужно что-то настолько простое, насколько это возможно, что легко понять.

Имеют ли смысл такие инструменты, как пакет RedGate, для такого рода сценариев, или мы должны использовать скрипты с поддержкой версий? Стоимость - это не столько проблема, это больше о создании «Ямы успеха», где обслуживание и развертывание БД является максимально простым и автоматизированным.