Как группа может отслеживать изменения в базе данных?

Какие методологии контроля версий помогают группам людей отслеживать изменения схемы базы данных?

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

Он называется schema_version (или миграцией, или чем угодно) и его целью является отслеживание структурных изменений или изменений данных в базе данных. Возможная структура (пример в MySQL):

create table schema_version (
     `when` timestamp not null default CURRENT_TIMESTAMP,
     `key` varchar(256) not null,
     `extra` varchar(256),
     primary key (`key`)
) ENGINE=InnoDB;

вставить в значения schema_version ( key, extra) ('001', 'версия схемы');

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

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

...

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

В противном случае RedGate имеет инструмент для интеграции управления исходным кодом в SSMS, а SQL Compare полезно для сравнения / синхронизации схем MS SQL Server. Visual Studio Database Edition также имеет встроенный инструмент сравнения схем .

Еще один такой вопрос привел меня к Migrator Dot Net, который я собираюсь начать исследовать в свободное время. Это выглядит как хороший метод, но это может быть больше временных / накладных инвестиций, чем вы готовы сделать.

eiefai уже упомянул таблицу, которая должна существовать во всех проектах с базой данных . Это отличный пост в блоге, но IMO это лишь часть пути к работающему решению для контроля версий баз данных. Я думаю, что любая попытка «ответить» на этот вопрос в реальном мире должна учитывать некоторую другую информацию о VCS и базах данных:

• Методология Agile Data
• Книга "Рефакторинг базы данных"
• Статья Мартина Фаулера "Эволюционный дизайн базы данных"
• Инструмент Liquibase
• Приличное видео со Скоттом Эмблером, представляющим его мысли о "гибких базах данных"

Я думаю, что есть несколько разных подходов к этому вопросу. Я полагаю, что угол «сначала инструмент» будет меняться в зависимости от платформы и личных предпочтений. Например: я использую проект базы данных в MS Visual Studio, но я не уверен, что это отличное решение для MySQL. Я также знаю людей, которые продают свои любимые инструменты от Redgate, Erwin, Embarcadero и т. Д.

В этом вопросе также есть ракурс «сначала процесс», который (надеюсь) будет вновь рассмотрен на этом сайте в последующих вопросах. Ключевыми моментами в этом процессе являются получение схемы под контролем исходного кода и управление изменениями, так что вы можете применить изменения схемы от версии "x" к версии "y" в значительной степени по требованию.

Окончательный ответ на эту тему в конечном итоге будет выглядеть как книга, поэтому, вероятно, стоит начать с ссылки на нее: Redgate недавно опубликовал бесплатную книгу под названием « Руководство Red Gate по разработке на основе SQL Server », и пока есть там много дискуссий, это очень хорошее место для дебатов, ИМО. Вопреки названию, большая часть материала в этой книге достаточно общая, чтобы ее можно было применить к любой БД (не только к SQL Server) и к любому набору инструментов (не только к Redgate). Если вы еще этого не видели, по крайней мере, это стоит того.

Наконец, возможно, стоит добавить ссылку в «устаревшем ответе» от stackoverflow .

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

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