Подготовка основы

Nov. 13, 2017

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

Предостережения

В качестве предисловия я должен сказать, что есть много работающих стратегий версионирования баз данных. Я не предлагаю единый и истинно верный вариант. Моя цель состоит в том, чтобы выкатить изменения базы данных в последовательном, проверяемом и воспроизводимым образом. Так как я привык работать с довольно большими схемами баз данных, то я не хочу использовать скрипты которые выполняются в течение 6 часов и тем самым заморозят на долго продакшен систему. Опасения которые я озвучил формируют мой ход мышления и стратегии. В каждом приложении с базой данных все изменения её схемы должны быть под контролем системы контроля версий, для этого Вам стоит подумать как реализовать это в ваших условиях наиболее простым путём.

создание базиса Данный текст является переводом. Оригинал по ссылке

Базис

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

Скорее всего вы не прейдёте к пониманию структуры базы в 1-й день проекта. Я бы предложил дать начальному дизайну схемы немного “притереться”, чтобы вам не пришлось создавать огромное количество изменений. Это может звучать как будто я советую вам проводить большие исследования, до создания схемы - но это вообще не так. Вы можете продвинуться достоточно далеко в разработке приложения, при помощи in-memory data, fake-ов, stub-ов, mock-ов и unit test-ов. После того как модель в коде начинёт стабилизироваться, вы можете начать думать о схеме, необходимой для сохранения всех данных. Если вы используете ORM, то настало время генерировать первую схему вашей базы.

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

Но как?

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

Хотя, на самом деле никто не делает это таким способом. Большинство из нас используют инструменты, которым мы указываем базу данных и эти инструменты генерируют один или несколько сценариев. Одним людям нравится генерировать все скрипты в один большой файл. Другим нравится генерировать один скрипт файл для каждого объекта базы данных. SQL Server Management Studio обеспечивает оба этих подхода. Я видел оба подхода в работе, но подход “один файл на объект” кажется неудобным при постоянной работе, особенно если число объектов вырастет до тысяч.

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

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

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

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

Я почти забыл самый важный ингредиент!

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

CREATE TABLE [DBO]. [SchemaChanges] (
    [ID] [INT] IDENTITY (1,1) NOT NULL,
    [MajorReleaseNumber] [VARCHAR] (2) NOT NULL,
    [MinorReleaseNumber] [VARCHAR] (2) NOT NULL,
    [PointReleaseNumber] [VARCHAR] (4) NOT NULL,
    [ScriptName] [VARCHAR] (50) NOT NULL,
    [DateApplied] [DateTime] NOT NULL,
    CONSTRAINT [PK_SchemaChangeLog]
        PRIMARY KEY CLUSTERED ([SchemaChangeID] ASC)
)

Скрипт схемы базиса БД должен в последнем шаге установить версию 1.0:

INSERT INTO [SchemaChangeLog]
    ([MajorReleaseNumber]
    , [MinorReleaseNumber]
    , [PointReleaseNumber]
    , [ScriptName]
    , [DateApplied])
VALUES 
    ('01'
    , '00'
    , '0000'
    , 'initial install'
    , GETDATE ())

Цикл статей: