Здравствуйте.
Помогите пожалуйста разобраться, как стоит организовать контроль версий СУБД.

Мое предположение такое (очень кажется, что где-то я ошибаюсь и можно схему упростить):
1. В текущей базе ввел таблицу с 2 параметрами: версия базы (1.0.2) и версия скриптов (1.0.2)
2. В базе создал процедуру dbo.Deploy (которая впоследствии будет накатывать на базу данные справочников)
3. Сделал бэкап пустой базы (без пользовательских данных, но со всеми необходимыми справочниками и с версиями). Этот бэкап будет у нас отправной точкой для развертки нового продакшна.
4. Поставил SQL Source Control от Red Gate, пока триалка.
5. Поместил схему своей базы в SVN (Link DataBase to source Control)

Подготовка закончилась, теперь собственно сами операции по обновлению БД
Каждый из разработчиков создает у себя на локале базу, восстанавливает ее из бэкапа, делает upgrade из SQl Source Controla и запускает процедуру Deploy.
Делает какие-то свои изменения, если изменения затрагивают не только схему, но и справочные данные, то разработчик добавляет в dbo.Deploy скрипт, назовем его (1.0.2 -> 1.0.3), который делается только на версии скриптов 1.0.2 и по завершению обновляет версию до 1.0.3.
И перед самым коммитом, также в dbo.Deploy меняет версию базы (обязательно, даже если не добавлял скрипт).

В итоге каждая база у нас будет версионирована, и уменьшается количетсво миграционных sql (теперь при изменении схемы Sql Source Control будет это делать за нас).
Но как минусы получаем 2 лишних действия, которые разработчик должен не забывать делать: 1. Изменять версию базы перед коммитом и не забывать запускать процедуру Deploy при развертке новой версии БД.

Подскажите как эту схему можно сделать попроще, может кто-то на практике применял более надежную схему?