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

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

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

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

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

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

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

Сами базы данных? нет

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

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

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

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

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

Проверьте 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 ... Create». Таким образом, вы можете в любое время выполнить откат к более ранней версии, указав сборку в папке, в которую хотите установить версию.

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

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

В Ruby On Rails это обрабатывается платформой с помощью «миграций». Каждый раз, когда вы изменяете базу данных, вы создаете сценарий, который применяет изменения и проверяет его в системе контроля версий.

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

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

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

Схема БД «измельчается» для создания множества мелких файлов .sql, по одному на команду DDL, описывающую БД.

+ том

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

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

Поскольку схема «измельчена» в файлы sql, система управления исходным кодом работает нормально.

Одна проблема заключается в том, что вам нужно иметь другое мышление, когда вы используете проект БД. У инструмента есть «проект БД» в VS, который представляет собой просто sql, плюс автоматически сгенерированная локальная база данных, которая содержит схему и некоторые другие данные администратора - но нет данных вашего приложения, плюс ваша локальная база данных dev, которую вы используете для разработка данных приложения. Вы редко знаете о автоматически сгенерированной базе данных, но вы должны знать ее там, чтобы оставить ее в покое :). Этот специальный БД хорошо узнаваем, потому что в его имени есть Guid,

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

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

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

+ том

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете сделать это, используя MySQL Query Browser или mysql client.Voila! Ваша модель и база данных теперь синхронизированы!

Источник: 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.sqlsubversion. В качестве ручного шага в процессе сборки мы сравниваем предыдущий currency.sql с последним и пишем скрипт обновления.

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

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

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

Я считаю, что каждая БД должна находиться под контролем исходного кода, и разработчики должны иметь простой способ создания своей локальной базы данных с нуля. Вдохновленный 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 под капотом), что должно сделать его настолько простым в использовании, что разработчики не будут разочарованы принятием процесса.

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

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

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

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

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

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

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

Я использовал инструмент dbdeploy от ThoughtWorks по адресу http://dbdeploy.com/ . Это поощряет использование сценариев миграции. В каждом выпуске мы объединяли сценарии изменений в один файл, чтобы облегчить понимание и позволить администраторам баз данных «благословлять» изменения.

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

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

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

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

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

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