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

Уточнение

Базы данных

Я предполагаю, что мне не нужно объяснять, что такое база данных или что SQL Server — это особая система баз данных, то есть специальное программное обеспечение для управления базами данных.

Схема базы данных как код

Разработчикам программного обеспечения , работающим с базами данных, желательно уметь поддерживать « схему » базы данных, т. е. информацию о ее структуре, в виде « кода ». Этот код должен позволить кому-то создать базу данных с той же «схемой», которая представлена ​​в коде. Код может быть в форме операторов DDL ( язык определения данных ), например, код SQL , обычно в его версии для конкретного поставщика, который используется для создания таких объектов, как таблицы и индексы в базе данных, или он может быть в общем виде. язык программирования , например Java , Ruby , C#, так далее.

Контроль версий и код

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

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

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

Развертывание программного обеспечения

« Развертывание » в контексте разработки программного обеспечения и обслуживания программного обеспечения включает «... все действия, которые делают программную систему доступной для использования». В контексте этого вопроса меня интересуют рекомендации по программным средствам для предоставления определенной версии схемы базы данных в виде конкретных конкретных экземпляров баз данных в СУБД SQL Server.

Пример

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

Некоторые конкретные критерии, упомянутые в комментариях

«выберите запись управления версиями, содержащую схему, (пере)оцените БД для соответствия (что именно это означает?»

Схема базы данных представлена ​​в виде кода в системе контроля версий. Меня не интересуют инструменты, работающие напрямую с контролем версий. Инструменты, в отношении которых этот вопрос запрашивает рекомендации, должны иметь возможность использовать «версию» схемы базы данных. Примером «версии» схемы может быть код, представляющий схему для конкретной версии («фиксация» в Git) или определенный тег/метка для систем контроля версий, которые поддерживают такие функции.

Вот основной список функций, которые должны быть предоставлены инструменту для «(пере)оценки [целевой] БД для соответствия»:

Столы

• Если таблица существует в исходной схеме, но не существует в целевой базе данных, инструмент должен создать таблицу в целевой базе данных. Это должно включать вспомогательные объекты, такие как ключи, ограничения, значения по умолчанию, индексы, триггеры и т. д.
• Если таблица не существует в исходной схеме, но существует в целевой базе данных, инструмент должен предоставить средства для указания, следует ли удалять таблицу в целевой базе данных. [Эта настройка может применяться ко всем таким таблицам.]

Столбцы таблицы

• ^{Если столбец существует в таблице в исходной схеме, но отсутствует в одной} и той же таблице в целевой базе данных, его следует создать в целевой базе данных. Поскольку операторы DDL для большинства (?) СУБД уже предоставляют способы указать начальное значение новых столбцов для существующих таблиц (например, особенно для новых столбцов, которые не допускают NULLзначений), я не знаю, нужно ли предусмотреть что-то особенное. самим инструментом, чтобы справиться с этим. Однако , если рекомендуемый инструмент использует некоторую форму «кода схемы», которая не является стандартными операторами DDL соответствующей СУБД ² , тогда инструмент должен предоставлять некоторые средства для указания начальных значений добавляемых столбцов.
• Если столбец таблицы не существует в исходной схеме, но существует в целевой базе данных, инструмент должен предоставить средства для указания, следует ли удалять столбец в целевой базе данных. [Эта настройка может применяться ко всем таким столбцам таблицы.]
• Если один и тот же ^{столбец} таблицы существует как в исходной схеме, так и в целевой базе данных, но они относятся к разным типам или существуют другие различия (например, длина, числовой масштаб и т. д.), инструмент должен изменить столбец в целевой базе данных на сопоставьте исходную схему и приложите все усилия, чтобы сохранить существующие данные в этом столбце . Для рекомендуемого инструмента вполне допустимо выходить из сообщения об ошибке, если он не может преобразовать существующие данные без потерь (например, если длина столбца уменьшена и данные необходимо усечь).

Вспомогательные объекты таблицы (таблиц)

Некоторые примеры этих объектов включают первичные ключи, ограничения внешнего ключа, значения по умолчанию и индексы.

• Если объект, вспомогательный для какой-либо таблицы, существует в исходной схеме, но отсутствует в целевой базе данных, он должен быть создан в целевой базе данных. Как и выше, для создания новых столбцов таблицы инструмент должен иметь возможность обрабатывать сценарии, связанные с возможными конфликтами или ошибками при добавлении вспомогательного объекта. Для инструмента совершенно нормально просто предоставить людям, поддерживающим код схемы, возможность убедиться, что любые конфликты или ошибки обрабатываются должным образом — для инструмента вполне допустимо выйти из сообщения об ошибке, если он сталкивается с конфликтом или ошибкой, подобной этой.
• Если объект, вспомогательный для какой-либо таблицы, не существует в исходной схеме, но существует в целевой базе данных, инструмент должен предоставить средства для указания, следует ли удалять вспомогательный объект в целевой базе данных. [Эта настройка может применяться ко всем таким объектам.]
• Если один и тот же ^объект существует как в исходной схеме, так и в целевой базе данных, инструмент должен изменить (или удалить и заново создать) объект в целевой базе данных, чтобы он соответствовал исходной схеме.

Другие объекты

Под «другим объектом» я подразумеваю такие объекты, как представления, хранимые процедуры, определяемые пользователем функции и т. д. Эти объекты обычно (?) можно безопасно удалить и воссоздать. Рекомендуемый инструмент должен иметь возможность удалять и воссоздавать эти объекты в необходимом порядке для объектов, которые зависят от других таких объектов (например, представление, которое ссылается на другое представление).

• Если другой объект и т. д. существует в исходной схеме, но отсутствует в целевой базе данных, он должен быть создан в целевой базе данных.
• Если другой объект, такой как представление, бла-бла-бла, не существует в исходной схеме, но существует в целевой базе данных, инструмент должен предоставить некоторые средства указания, следует ли отбрасывать другой объект в целевой базе данных. [Эта настройка может применяться ко всем таким другим объектам.]
• Если один из этих объектов существует как в исходной схеме, так и в целевой базе данных, инструмент должен изменить (или удалить и заново создать) объект в целевой базе данных, чтобы он соответствовал исходной схеме.

Статические данные

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

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

Заметки

¹ На самом деле это потенциально тонкий момент! Большинство инструментов, вероятно, будут реализовывать «одинаковость» для объектов базы данных, имеющих одно и то же имя . Но есть альтернативы, по крайней мере, для некоторых СУБД, например, в SQL Server, расширенные свойства могут использоваться для реализации формы постоянной идентификации для объектов базы данных, которая не зависит от имени объекта. Это было бы удобно, поскольку тогда инструмент мог бы автоматически обрабатывать (по крайней мере, некоторые) случаи, когда объекты переименовываются.

² Я спросил конкретно о SQL Server, но на данный момент мне бы очень понравилось, если бы кто- нибудь вообще дал ответ на этот вопрос для любой СУБД.