Лучшие методологии контроля изменений в базе данных

Самый простой способ, который я видел, это сделать без помощи внешнего инструмента, это создать «заплату схемы», если хотите. Патч схемы — это просто простой сценарий t-sql. Исправлению схемы присваивается номер версии в сценарии, и этот номер сохраняется в таблице базы данных для получения изменений.

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

Хорошая книга с такими подробностями называется Рефакторинг баз данных< /а>.

Если вы хотите использовать внешний инструмент, вы можете посмотреть проект Ruby's Migrations или аналогичный инструмент на C# под названием Migrator.NET. Эти инструменты работают, создавая классы С#/классы ruby ​​с миграцией «вперед» и «назад». Эти инструменты более многофункциональны, потому что они знают, как двигаться вперед и назад в исправлениях схемы. Однако, как вы заявили, вас не интересует внешний инструмент, но я подумал, что все равно добавлю это для других читателей.

Мне больше понравилась эта серия: http://odetocode.com/Blogs/scott/archive/2008/02/03/11746.aspx

В моем случае у меня создается скрипт каждый раз, когда я меняю базу данных, я назвал скрипт как 00001.sql, n.sql, и у меня есть таблица с номером последнего скрипта, который я выполнил. Вы также можете ознакомиться с документацией по базе данных.

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

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

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

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

У меня есть подход, основанный на модели (извините, не реализованный в данный момент), в котором изменения схемы «моделируются» (например, на xml), а во время обновления процессор (например, программа ac#) создает все необходимые «sql "и например перемещает данные в «dropDatabase». данные могут находиться там, и если по какой-то причине мне нужно восстановить некоторые из удаленных данных, я могу просто сделать это с помощью процессора. я думаю, что через какое-то время (годы) этот подход не так уж плох, потому что в противном случае разработчики не трогают «старые» таблицы, потому что они больше не знают, действительно ли нужна таблица или столбец. с таким подходом вы не сильно рискуете, если что-то уроните!

Что я делаю:

• Все команды DDL, необходимые для воссоздания схемы (а также хранимых процедур, индексов и т. д.), находятся в сценарии.
• Чтобы убедиться, что со сценарием все в порядке, время от времени его тестируют (создайте базу данных, запустите сценарий, восстановите резервную копию и проверьте, работает ли база данных).
• Для контроля изменений скрипт хранится в системе контроля версий (обычно я использую Subversion).

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