Используете ли Вы систему управления версиями для элементов базы данных? [закрытый]

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

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

тем не менее, я знаю, как эта история продолжается. Это только вопрос времени, когда что-то пойдет не так и что-то пропадет.

есть ли какие-либо лучшие практики для этого? Какие стратегии сработали для вас?

30 ответов


следует читать получить базу данных под контролем версий. Проверьте серию сообщений К. Скотта Аллена.

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


сами базы данных? Нет!--1-->

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

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


Я абсолютно люблю Rails ActiveRecord миграции. Он абстрагирует скрипт DML to ruby, который затем может быть легко версирован в вашем исходном репозитории.

, с немного работы, вы могли бы сделать то же самое. Любые изменения DDL (ALTER TABLE и т. д.) может храниться в текстовых файлах. Сохраните систему нумерации (или штамп даты) для имен файлов и примените их последовательно.

Rails также имеет таблицу "версия" в БД, которая отслеживает последнюю примененную миграцию. Вы может сделать то же самое легко.


проверить LiquiBase для управления изменениями базы данных с помощью системы управления версиями.


вы никогда не должны просто войти в систему и начать вводить команды "ALTER TABLE" для изменения производственной базы данных. Проект я на базе на каждого клиента, и поэтому каждое изменение в базе данных производится в двух местах, дамп файл, который используется, чтобы создать новую базу данных на новом сайте поддержки, и обновления файл, который запускается на каждом обновление которое проверяет ваши текущие версии базы данных число с наибольшим количеством в файл и обновляет базы данных. Так, например, последние пару обновлений:

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

Я уверен, что есть лучший способ сделать это, но он работал для меня до сих пор.


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


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

Я считаю, что это было сделано с NaNt/CruiseControl.


да, я думаю, важно, чтобы версия вашей базы данных. Не данные, а схема наверняка.

в Ruby On Rails это обрабатывается платформой с "миграциями". Каждый раз, когда вы изменяете БД, вы делаете сценарий, который применяет изменения и проверяет его в системе управления версиями.

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


новые проекты баз данных в Visual Studio предоставляют сценарии управления версиями и изменения.

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

схема БД "измельчается", чтобы создать много, много маленьких .файлы sql, по одному на команду DDL, которая описывает БД.

+Тома


дополнительная информация 2008-11-30

Я использую его в качестве разработчика в течение прошлого года и очень нравится. Это позволяет легко сравнить мою работу dev с производством и создать скрипт для использования в выпуске. Я не знаю, отсутствуют ли функции, необходимые DBAs для проектов "корпоративного типа".

поскольку схема "измельчается" в sql-файлы, элемент управления версиями работает нормально.

One gotcha заключается в том, что вам нужно иметь другое мышление при использовании проекта db. Инструмент имеет "проект БД" в VS, который является только sql, плюс автоматически сгенерированная локальная база данных, которая имеет схему и некоторые другие данные администратора, но ни один из ваших данных приложения, а также локальная БД разработчиков, которую вы используете для работы с данными приложений. Вы редко знаете о автоматически генерируемой БД, но вы должны знать его там, чтобы вы могли оставить его в покое :). Эта специальная БД четко распознается, потому что в ее названии есть Guid,

проект VS DB делает хорошую работу интеграция изменений БД, внесенных другими членами команды в локальный проект/связанную БД. но вам нужно сделать дополнительный шаг, чтобы сравнить схему проекта с вашей локальной схемой dev db и применить моды. Это имеет смысл, но поначалу кажется неловким.

DB проекты являются очень мощным инструментом. Они не только генерируют сценарии, но и могут применять их немедленно. Убедитесь, что не уничтожите с ним свою производственную БД. ;)

Мне очень нравятся проекты VS DB, и я ожидаю использовать этот инструмент для всех моих проектов db в будущем.

+Тома


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

Я могу предложить использование надстройки SSMS с именем Управление Версиями ApexSQL. Это позволяет разработчикам легко сопоставлять объекты базы данных с системой управления версиями с помощью мастера непосредственно из SSMS. Надстройка включает поддержку TFS, Git, Subversion и других систем SC. Он также включает поддержку статических данных управления источником.

после загрузки и установки ApexSQL Source Control, просто щелкните правой кнопкой мыши базу данных, которую вы хотите контролировать версии и перейдите к ApexSQL Source Control подменю в SSMS. Выберите параметр связать базу данных с системой управления версиями, выберите систему управления версиями и модель разработки. После этого вам нужно будет предоставить информацию о входе в систему и строку репозитория для выбранной вами системы управления версиями.

вы можете прочитать эту статью для получения дополнительной информации: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/


Я делаю, сохраняя скрипты создания / обновления и скрипт, который генерирует sampledata.


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

У нас также есть задачи ant, которые могут воссоздать БД, когда это необходимо.

кроме того, SQL затем помечается вместе с исходным кодом, который идет с ним.


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


наиболее удачные схемы, которые я использовал в проекте сочетались и разностных файлов SQL. В принципе, мы бы взяли резервную копию нашей БД после каждого выпуска и сделали дамп SQL, чтобы мы могли создать пустую схему с нуля, если нам нужно. Затем в любое время, когда вам нужно внести изменения в БД, вы добавите Alter scrip в каталог sql под контролем версий. Мы всегда будем приставлять порядковый номер или дату к имени файла, чтобы первое изменение было что-то вроде 01_add_created_on_column.sql, и следующий скрипт будет 02_added_customers_index. Наш компьютер CI будет проверять их и запускать последовательно на новой копии БД, которая была восстановлена из резервной копии.

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


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


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

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

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


Я использую SQL CREATE scripts, экспортированные из MySQL Workbech, затем, используя их функциональность "Export SQL ALTER", я получаю серию сценариев создания(пронумерованных, конечно) и сценариев alter, которые могут применять изменения между ними.

3.- Экспорт SQL ALTER script Обычно вам придется писать операторы ALTER TABLE вручную, отражая изменения, внесенные в модель. Но вы можете быть умным и позволить Workbench сделать тяжелую работу за вас. Просто выбрать Файл - > Экспорт - > Forward Engineer SQL ALTER Script... из главного меню.

Это предложит вам указать файл SQL CREATE, с которым должна сравниваться текущая модель.

выберите сценарий создания SQL на шаге 1. Затем инструмент создаст сценарий ALTER TABLE для вас, и вы можете выполнить этот сценарий для своей базы данных, чтобы обновить его.

вы можете сделать это с помощью браузера запросов MySQL или клиента mysql.Вуаля! Модели и база данных теперь синхронизирована!

источник: MySQL Workbench Community Edition: руководство по синхронизации схемы

все эти скрипты, конечно, находятся внутри под контролем версий.


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


было много дискуссий о самой модели базы данных ,но мы также храним необходимые данные.SQL-файлов.

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

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

у нас будет файл с именем currency.sql под subversion. В качестве ручного шага в процессе сборки мы сравниваем предыдущую валюту.sql до последнего и написать сценарий обновления.


мы версия и контроль источника все, что окружает наши базы данных:

  • DDL (создание и изменение)
  • DML (справочные данные, коды и т. д.)
  • изменения модели данных (с помощью ERwin или ER/Studio)
  • изменения конфигурации базы данных (разрешения, объекты безопасности, общие изменения конфигурации)

мы делаем все это с автоматизированными заданиями, используя Change Manager и некоторые пользовательские скрипты. У нас есть Change Manager мониторинг этих изменения и уведомление, когда они будут сделаны.


Я считаю, что каждая БД должна быть под контролем системы управления версиями, и разработчики должны иметь простой способ создать свою локальную базу данных с нуля. Вдохновленный Visual Studio для профессионалов баз данных, я создал инструмент с открытым исходным кодом, который создает сценарии баз данных MS SQL и предоставляет простой способ их развертывания в локальном ядре БД. Попробуйте http://dbsourcetools.codeplex.com/ . Повеселись, - Натан.


Если ваша база данных SQL Server, у нас может быть только решение, которое вы ищете. Теперь выпущен SQL Source Control 1.0.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

это интегрируется в SSMS и обеспечивает клей между объектами базы данных и вашими VCS. "Сценарий" происходит прозрачно (он использует SQL Compare engine под капотом), что должно сделать его настолько простым в использовании, что разработчики не будет препятствовать принятию этого процесса.

альтернативным решением Visual Studio является ReadyRoll, который реализован как подтип проекта базы данных SSDT. Это требует подхода, основанного на миграции, который больше подходит для требований автоматизации команд DevOps.


Я использую SchemaBank для управления версиями все изменения схемы моей базы данных:

  • С 1-го дня я импортирую в него дамп схемы БД
  • я начал изменять свой дизайн схемы с помощью веб-браузера (потому что они SaaS / cloud-based)
  • когда я хочу обновить свой сервер БД, я генерирую сценарий изменения (SQL) из него и применяю к БД. В Schemabank они поручают мне выполнить мою работу в качестве версии, прежде чем я смогу создать сценарий обновления. Я например, такая практика, чтобы я всегда мог отследить, когда мне нужно.

наше правило команды никогда не касается сервера БД сразу без хранить проектная работа сперва. Но бывает так, что кто-то может поддаться искушению нарушить правило ради удобства. Мы снова импортируем дамп схемы в schemabank и позволим ему сделать diff и bash кого-то, если будет найдено несоответствие. Хотя мы могли бы генерировать сценарии alter из него, чтобы синхронизировать дизайн нашей БД и схемы, мы просто ненавижу это.

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

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


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


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

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


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

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

Удачи вам, чем скорее вы попробуете это, тем скорее у вас будут проблемы.


Я использовал инструмент dbdeploy от Thoughtworksбыл на http://dbdeploy.com/. Он рекомендует использовать скрипты миграции. В каждом выпуске мы объединяли сценарии изменений в один файл, чтобы облегчить понимание и позволить DBAs "благословлять" изменения.


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

инструмент, который я использовал в прошлом, который помог с этим, - это SQL Delta. Он покажет вам различия между двумя базами данных (SQL server/Oracle, я считаю) и сгенерирует все сценарии изменений, необходимые для миграции A->B. Еще одна хорошая вещь, которую он делает, - это показать все различия между содержимым базы данных между производственной (или тестовой) БД и вашей БД разработки. Поскольку все больше и больше приложений хранят конфигурацию и состояние, которое имеет решающее значение для их выполнения в таблицах базы данных, может быть реальной болью иметь сценарии изменений, которые удаляют, добавляют и изменяют правильные строки. язык SQL Delta показывает строки в базе данных так же, как они выглядели бы в инструменте Diff - изменены, добавлены, удалены.

отличный инструмент. Вот ссылка: http://www.sqldelta.com/


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

RedGate также делает снимки данных, хотя я лично не работал с ними, они так же надежны.


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