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

Фон

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

Все таблицы были "create if not exists", и все SP и т.д. были сброшены и воссозданы.

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

Вопрос

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

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

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

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

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

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

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

Ответ 1

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

Это блог-сайт ведущего архитектора DBPro: http://blogs.msdn.com/gertd/archive/2008/11/25/visual-studio-team-system-2008-database-edition-gdr-rtm.aspx

Ответ 2

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

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

Ответ 3

Если вы уже используете инструменты 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)

Ответ 4

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

Он построен поверх структуры .net. и работает с несколькими форматами базы данных, включая 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");  
       }  
   }

Ответ 5

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

Во время разработки разработчик записывает изменение схемы script и запускает ее против базы данных разработки. Каждое изменение требуется для добавления строки в таблицу dba.change_info, содержащую номер изменения и краткое описание. Чтобы отменить изменение, можно просто запустить первый его раздел. Для SQL Server idempotence секции отката обрабатывается путем проверки sysobjects и т.д. Перед выпуском команд DROP, аналогичных конструкциям "drop... if exists". Изменения схемы могут потребовать переноса данных, если модель изменяется, а не просто добавляется, а также используется для поддержания ссылочных данных.

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

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

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

... непрерывная интеграция базы данных и схема миграции схем

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

Ответ 10

На работе мы используем мощный инструмент, который входит в состав 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 автоматически генерирует поле "created_at" и поле "updated_at".

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