Структура базы данных и контроль источников - лучшие практики

Question

Фон

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

Все таблицы были «созданы, если не существует», а все SP и т. Д. Были удалены и созданы заново.

До настоящего времени, и я сейчас работаю в месте, где база данных является главной, и нет контроля над исходным кодом для объектов БД, но мы используем инструменты redgate для обновления нашей производственной базы данных (сравнение SQL), что очень удобно, и требует мало работы.

Вопрос

Как вы обрабатываете ваши объекты БД? Мне нравится держать их под контролем исходного кода (и, поскольку мы используем GIT, я хотел бы иметь возможность обрабатывать конфликты слияния в сценариях, а не в БД), но я буду вынужден пройти мимо простота использования SQL сравнения для обновления базы данных.

Я не хочу, чтобы мы обновляли скрипты в GIT, а затем использовали сравнение SQL для обновления производственной базы данных из нашей базы данных DEV, так как я бы предпочел «одну версию правды», но я не Я действительно хочу переписать специальную часть программного обеспечения для объединения всего множества сценариев.

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

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

Каковы лучшие практики для сценариев базы данных под управлением кода

---

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

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

Answer 1

Посмотрите на эту серию из пяти частей, посвященную принципам и практикам управления версиями базы данных (К. Скотт Аллен):

1. Три правила работы с базой данных
2. Базовая линия
3. Смена скриптов
4. Представления, хранимые процедуры и тому подобное
5. Ветвление и слияние

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

Answer 2

Все наши объекты базы данных находятся под контролем исходного кода с использованием Visual Studio Database Edition (DBPro). Это замечательный инструмент, который управляет нашей схемой версией, выполняет сборки, проверки, позволяет анализировать код, сравнивать схемы, развертывать, сравнивать данные, выполнять рефакторинг и т. Д. Он был спроектирован с нуля как система управления БД и контроля версий. Настоятельно рекомендуется.

Это блог-сайт ведущего архитектора для DBPro: нажмите здесь

Answer 3

Используя стороннюю надстройку SSMS ApexSQL Source Control , объекты базы данных могут автоматически создаваться в сценарии и передаваться в удаленный репозиторий Git или даже в клонированный локальный, если вы предпочитаете работать с локальным репозиторием. .

ApexSQL Source Control поддерживает систему контроля версий Git из коробки. Это означает, что вам не нужно устанавливать дополнительный клиент Git. Кроме того, ветвление и слияние интегрированы и доступны через интерфейс надстройки.

Answer 4

Предполагая, что вы используете .net Framework, взгляните на Fluent Migrator , а также на подкаст Hearding Code , в котором рассказывается о проекте.
На мой взгляд, основная цель состоит в том, чтобы легко кодировать миграции, как вы делаете обычное кодирование, используя свободный интерфейс, используя независимый от базы данных подход.

Он построен поверх .net Framework. и работает с рядом форматов баз данных, включая SQL Server, SqlLite и MySQL.

Преимущество этого подхода в том, что он совместим с остальным кодом и поэтому может управляться SCM

Пример:

   [Migration(1)]   
   public class CreateProjectsTable : Migration   
   {   
       public void Up()   
       {   
          Create.Table("Projects")              
            .WithIdColumn()             
            .WithColumn("Name").AsString().NotNullable()                
            .WithColumn("Position").AsInt32().NotNullable()             
            .WithColumn("Done").AsBoolean().NotNullable();
       }  
       public void Down()  
       {  
           Database.RemoveTable("Projects");  
       }  
   }

Answer 5

Если вы уже используете инструменты Red Gate, вы можете рассмотреть возможность использования SQL Source Control, который работает бок о бок с SQL Compare и SQL Data Compare, чтобы позволить одной версии истины существовать в системе контроля версий. В данный момент он находится в раннем доступе, но большая часть его функциональности уже опробована. Вы можете скачать его с http://www.red -gate.com / Products / SQL_Source_Control / index.htm . Однако на данный момент он поддерживает только SVN и TFS. Вы стандартизировали на GIT?

Дэвид (менеджер по продукции в Red Gate)

Answer 6

Я не очень знаком с инструментарием RedGate, но если он похож на dbGhost , должна быть утилита, которая позволяет вам записывать объекты базы данных в файлы по одному на объект. В этом случае я бы предложил следующее:

• добавить ежедневное (или часть сборки) задание для обратного инжиниринга базы данных DEV в структуру каталогов
• , затем сравните его с тем, что у вас есть в репозитории (с помощью простого diff), и, в основном, FAIL задание на сборку и сообщите diff, если есть. Это будет указывать на то, что структура базы данных DEV изменилась и не отражена в исходном элементе управления,
• , который укажет разработчику добавить изменения в систему контроля версий (для этого даже используйте сообщенный файл .diff)

Если у вас много баз данных DEV (по одной на пользователя или ветку разработки), и это слишком громоздко, то, вероятно, лучше было бы выполнить такую ​​задачу в версии базы данных STAGE (TEST непосредственно перед выпуском) по адресу В этот момент вы сохраните схему PROD в репозитории и обновите ее из STAGE только на этапе предварительного тестирования, когда вы убедитесь, что ваши изменения схемы также находятся в репозитории.

Таким образом, разработчики могут продолжать работать в обычном режиме: сначала измените схему в базе данных DEV, и, надеюсь, вы получите баланс между flexibility и one truth, который вы хотели бы.

В моей команде мы добавляем изменения в VCS, как только мы меняем базу данных DEV, но у нас все еще есть такая задача для сравнения схемы между различными базами данных (DEV, STAGE и PROD). По сути, мы следуем тому, что я когда-то ответил в Как вы должны построить свою базу данных из системы контроля версий? .

Answer 7

У нас есть система, в которой база данных номинально является главной в нашей системе контроля версий, мы поддерживаем последовательность сценариев «изменения схемы» (файлы .sql), каждый из которых отвечает за идемпотентный откат изменения, а затем применяя это. Каждый скрипт просто пронумерован, поэтому у нас есть 000.sql (который создает базу данных и устанавливает стандартные объекты), 001.sql и т. Д.

Во время разработки разработчик пишет сценарий изменения схемы и запускает его для базы данных разработки. Каждое изменение требуется для добавления в таблицу dba.change_info строки, содержащей номер изменения и краткое описание. Чтобы откатить изменение, можно просто запустить его первый раздел. Для SQL Server идемпотентность раздела отката обрабатывается путем изучения системных объектов и т. Д. Перед выполнением команд DROP - аналогично конструкциям «отбрасывать ... если существует». При изменении схемы может потребоваться выполнить миграцию данных, если модель изменяется, а не просто добавляется, а также используется для ведения справочных данных.

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

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

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

Answer 8

На работе мы интенсивно используем мощный инструмент, который входит в состав ActiveRecord (который является стандартным ORM, который поставляется с веб-фреймворком Rails , который называется Миграции .

Базовая миграция будет выглядеть следующим образом:

class AddSystems < ActiveRecord::Migration
  def self.up
    create_table :systems do |t|
      t.string  :name
      t.string  :label
      t.text    :value
      t.string  :type
      t.integer :position, :default => 1
      t.timestamps
    end
  end

  def self.down
    drop_table :systems
  end
end

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

rake db:migrate #run all outstanding migrations
rake db:rollback #roll back the last run migration
rake db:seed #fill the database with your seed data

Миграции имеют методы для создания таблиц, удаления таблиц, обновления таблиц, добавления индексов и т. Д. Полный набор. При переносе также автоматически добавляется столбец id, а в разделе t.timestamps автоматически создается поле «create_at» и поле «updated_at».

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

Answer 9

Для этой вещи есть специальный инструмент. Это называется Wizardby :

... инфраструктура непрерывной интеграции баз данных и миграции схем

Рабочий процесс Wizardby http://octalforty -wizardby.googlecode.com / svn / trunk / docs / img / database_versioning_with_wizardby.png

Answer 10

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

Справочные данные хранятся в электронной таблице Excel (также под контролем исходного кода), которая может генерировать сценарий SQL операторов INSERT для заполнения новых баз данных.

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

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