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

Ответ 1

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

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

Ответ 2

Базы данных сами? Нет

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

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

Вам не следует просто входить в систему и вводить команды "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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

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

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

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

+ Том

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

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

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

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

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

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

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

+ Том

Ответ 10

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

Я могу предложить использовать надстройку 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/

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

Ответ 14

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

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

Ответ 15

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

Ответ 16

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

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

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

Ответ 17

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

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

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

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

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

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

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

Ответ 18

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

Ответ 19

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

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

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

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

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

Ответ 20

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

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

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

Ответ 21

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

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

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

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

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

Ответ 22

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

Ответ 23

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

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

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

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

Ответ 24

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

Ответ 25

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

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

Ответ 26

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

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

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

Ответ 27

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

Ответ 28

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

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

Отличный инструмент. Ссылка здесь: http://www.sqldelta.com/

Ответ 29

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

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

Ответ 30

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