Как я могу поместить базу данных под git (контроль версий)?

Проверьте базы данных рефакторинга (http://databaserefactoring.com/) для кучки хороших методов для поддержания вашей базы данных в тандеме с изменениями кода.

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

Если вы хотите иметь полную восстанавливаемость, вы должны рассмотрите возможность архивирования журналов postgres WAL и используйте PITR (point in time recovery) для воспроизведения транзакций назад/вперед в определенные известные хорошие состояния.

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

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

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

EDIT:

дубликат, я имею в виду создание другая база данных с другим именем (например,my_db_2); не делать дамп или что-то в этом роде.

вместо того, чтобы вручную сбрасывать БД и сохранять ее в git, используйте Offscale DataGrove.

DataGrove-это в основном контроль версий БД - он отслеживает изменения всей БД (схемы и данных) и позволяет помечать версии в репозитории. Вы можете использовать его вместе с git и иметь его тег версии каждый раз, когда вы регистрируете код, и загружать правильное состояние DB всякий раз, когда вы вытаскиваете код.

в частности, относительно "Edit 2" - с DataGrove вы можете просто имейте две ветви БД, по одной для каждой из ветвей кода. Когда вы загружаете определенную ветвь кода, DataGrove автоматически воссоздает все состояние БД со всеми данными внутри для этой версии / ветви. Это означает, что вы можете переключаться между ветвями разработки с помощью одной простой команды.

использовать что-то вроде LiquiBase это позволяет сохранить контроль версий ваших файлов Liquibase. вы можете пометить изменения только для производства, и lb обновит вашу БД для производства или разработки (или любой схемы, которую вы хотите).

есть инструмент, который находится в стадии разработки под названием Klonio, бета-версия которого доступна для использования. Он поддерживает MongoDB и MySQL на данный момент.

конечно, он имеет интеграцию git, и вы можете сделать снимок только вашей схемы или даже включенных данных.

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

Он все еще находится в альфа-состоянии и построен для php.

http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/index.html

взгляните на RedGate SQL Source Control.

http://www.red-gate.com/products/sql-development/sql-source-control/

этот инструмент является оснасткой SQL Server Management Studio, которая позволит вам поместить вашу базу данных под управление версиями с помощью Git.

Это немного дорого в $495 за пользователя,но есть 28-дневная бесплатная пробная версия.

Примечание. Я никоим образом не связан с RedGate.

я столкнулся с этим вопросом, так как у меня есть аналогичная проблема, где что-то аппроксимирующее структуру каталогов на основе БД, хранит "файлы", и мне нужен git для управления им. Он распространяется через облако, используя репликацию, поэтому точка доступа будет через MySQL.

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

Git-это система, которая, по сути, хранит базу данных дельт (различий), которую можно собрать заново, чтобы воспроизвести контекст. Обычное использование git предполагает, что контекст является файловой системой, и эти дельты являются diff в этой файловой системе, но на самом деле все git-это иерархическая база данных дельт (иерархическая, потому что в большинстве случаев каждая Дельта-это фиксация с по крайней мере 1 родителями, расположенными в дереве).

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

Если вы хотите управлять изменениями, в базе данных у вас есть 2 дискретные проблемы, и я бы рассмотрел их отдельно (на вашем месте). Первый-схема, второй-данные (хотя в вашем вопросе данные состояния не являются чем-то вы обеспокоены). В прошлом у меня была проблема с базой данных Dev и Prod, где Dev мог вносить инкрементные изменения в схему, и эти изменения должны были быть задокументированы в CVS и предложены для жизни вместе с добавлениями к одной из нескольких "статических" таблиц. Мы сделали это, имея 3-ю базу данных под названием Cruise, которая содержала только статические данные. В любой момент можно было сравнить схему от Dev и Cruise, и у нас был скрипт, чтобы взять разницу этих 2 файлов и создать SQL файл, содержащий инструкции ALTER, чтобы применить его. Аналогично, любые новые данные могут быть дистиллированы в файл SQL, содержащий команды INSERT. Пока поля и таблицы только добавляются и никогда не удаляются, процесс может автоматизировать создание операторов SQL для применения дельты.

механизм, с помощью которого git генерирует дельты, является diff и механизм, с помощью которого он объединяет 1 или более дельт с файлом, называется merge. Если вы можете придумать способ для сравнения и слияния из другого контекста git должен работать, но, как уже обсуждалось, вы можете предпочесть инструмент, который делает это за вас. Моя первая мысль к решению, что это https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Tools какие детали, как заменить внутренний инструмент diff и слияния git. Я обновлю этот ответ, поскольку я придумаю лучшее решение проблемы, но в моем случае я ожидаю, что мне придется только управлять изменениями данных, пока-как БД основанное хранилище файлов может измениться, поэтому мое решение может быть не совсем тем, что вам нужно.

вы не можете сделать это без атомарности, и вы не можете получить атомарность без использования pg_dump или файловой системы snapshotting.

мой экземпляр postgres находится в zfs, который я иногда снимаю. Это примерно мгновенно и последовательно.

то, что вы хотите, по духу, возможно, что-то вроде Post Facto, который хранит версии базы данных в базе данных. Проверьте это презентация.

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

Я выпустил инструмент для sqlite, который делает то, что вы просите. Он использует пользовательский драйвер diff, использующий SQLite projects tool 'sqldiff', UUIDs в качестве первичных ключей и оставляет SQLite rowid. Он все еще находится в alpha, поэтому обратная связь приветствуется.

Postgres и mysql сложнее, так как двоичные данные хранятся в нескольких файлах и могут быть даже недействительными, если вы смогли сделать снимок.

https://github.com/cannadayr/git-sqlite

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

Я собираюсь следовать идеям в этом посте от Владимира Хорикова "лучшие практики управления версиями баз данных". В итоге я буду

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

в случае, если это помогает!

Я думаю, что X-Istence находится на правильном пути, но есть еще несколько улучшений, которые вы можете сделать для этой стратегии. Во-первых, используйте:

$pg_dump --schema ... 

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

далее выполните дамп данных для набора таблиц, содержащих configuration требуются для вашего приложения для работы (вероятно, следует пропустить пользовательские данные, etc), как значения по умолчанию формы и другие данные non-user modifiable данные. Вы можете сделать это выборочно, используя:

$pg_dump --table=.. <or> --exclude-table=..

это хорошая идея, потому что РЕПО может стать очень неуклюжим, когда ваша база данных достигает 100 МБ+ при выполнении полного дампа данных. Лучше создать резервную копию более минимального набора данных, необходимых для тестирования приложения. Если ваши данные по умолчанию очень велики, это все равно может вызвать проблемы.

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

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

наконец, взгляните на документация резервного копирования postgres если вы еще этого не сделали. Этот то, как вы комментируете резервное копирование "базы данных", а не дампа, заставляет меня задуматься, думаете ли вы о резервных копиях на основе файловой системы (см. раздел 23.2 предостережения).

на этот вопрос в значительной степени ответили, но я хотел бы дополнить ответ X-Istence и даны в здравом уме небольшим предложением.

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

с этим у вас есть как преимущество контроля версий, так и вы не тратите слишком много места.

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

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

Что я делаю в своих личных проектах, я храню всю свою базу данных в dropbox, а затем указываю MAMP, WAMP workflow, чтобы использовать ее прямо оттуда.. Таким образом, база данных всегда актуальна, когда мне нужно сделать некоторые разработки. Но это только для Дев! Живые сайты используют собственный сервер для этого, конечно! :)

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

вот как я делаю это:

поскольку у вас есть свободный выбор типа DB, используйте файловую БД, например, firebird.

создайте шаблон БД, который имеет схему, соответствующую вашей фактической ветви, и сохраните ее в своем репозитории.

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

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

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

на каждой машине у нас были файлы PHP, а также служба MySQL и папка с изображениями, которые пользователи будут загружать. Живой сервер вырос до 100K (!) повторяющиеся пользователи, дамп был около 2GB (!), папка изображения была около 50GB (!). К тому времени, как я ушел, сервер достиг предела своего процессора, ОЗУ и, самое главное, ограничений параллельного сетевого подключения (мы даже скомпилировали нашу собственную версию драйвера сетевой карты, чтобы максимально использовать сервер "lol"). Мы не могли (и вы не должны предполагать с вашим сайтом) поместите 2 ГБ данных и 50 ГБ изображений в GIT.

чтобы легко управлять всем этим в GIT, мы будем игнорировать двоичные папки (папки, содержащие изображения), вставляя эти пути к папкам .гитюдного. У нас также была папка называется SQL вне пути Apache documentroot. В этой папке SQL мы поместили бы наши файлы SQL от разработчиков в инкрементные числа (001.florianm.в SQL, 001.Джонс.в SQL, 002.florianm.SQL и т. д.). Эти файлы SQL также управлялись GIT. Первый файл sql действительно будет содержать большой набор схем БД. Мы не добавляем пользовательские данные в GIT (например, записи таблицы users или таблицы комментариев), но данные, такие как конфигурации или топология или другие данные сайта, поддерживались в файлах sql (и, следовательно, GIT). В основном это разработчики (которые лучше знают код), которые определяют, что и что не поддерживается GIT в отношении схемы SQL и данных.

когда он добрался до выпуска, администратор входит в систему на сервере dev, объединяет живую ветвь со всеми разработчиками и необходимыми ветвями на машине dev в ветвь обновления и толкнул ее на тестовый сервер. На тестовом сервере он проверяет, является ли процесс обновления для Live-сервера по-прежнему действительным, и в quick последовательность, указывает весь трафик в Apache на сайт-заполнитель, создает дамп БД, указывает рабочий каталог от "live" до "update", выполняет все новые файлы sql в mysql и переадресовывает трафик обратно на правильный сайт. Когда все заинтересованные стороны согласились после просмотра тестового сервера, администратор сделал то же самое с тестового сервера на живой сервер. После этого он сливает живую ветвь на производственном сервере, чтобы главная ветвь пересекала все серверы и перезагружала все живые ветви. Разработчики сами отвечали за ребазирование своих филиалов, но они, как правило, знают, что делают.

Если были проблемы на тестовом сервере, например. слияния имели слишком много конфликтов, затем код был возвращен (указывая рабочую ветвь обратно на "live"), и файлы sql никогда не выполнялись. В тот момент, когда файлы sql были выполнены, это рассматривалось как необратимое действие в то время. Если файлы SQL не работали должным образом, то БД была восстановлена используя дамп (и разработчики отчитались, за предоставление плохо протестированных файлов SQL).

сегодня мы поддерживаем как SQL-up, так и sql-down папку с эквивалентными именами файлов,где разработчики должны проверить, что оба файла SQL обновления, могут быть одинаково понижены. В конечном итоге это может быть выполнено с помощью скрипта bash, но это хорошая идея, если человеческие глаза продолжали следить за процессом обновления.

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

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

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

Я хотел бы поставить всю базу данных под контроль версий, что Database engine можно использовать, чтобы я мог поместить фактическую базу данных под контроль версий вместо его дампа?

Это не зависит от компонента Database engine. ПО Microsoft SQL Server существует множество программ управления версиями. Я не думаю, что эта проблема может быть решена с помощью git, вы должны использовать систему управления версиями схемы pgsql. Я не знаю, существует ли такая вещь или нет. не...

вот что я пытаюсь сделать в своих проектах:

• отдельные данные и схемы и данные по умолчанию.

конфигурация базы данных хранится в файле конфигурации, который не находится под контролем версий (.gitignore)

база данных по умолчанию (для настройки новых проектов) представляет собой простой файл SQL под управлением версий.

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

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

взгляните на другие большие проекты баз данных с открытым исходным кодом (piwik или ваша любимая система cms), все они используют updatescripts (1.sql, 2.sql, 3.Ш, 4.php.5.sql)

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

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

после этого в вашем общем updatescript (запустите обычные updatescripts, для особых случаев), а затем сравните схемы (дамп и текущую базу данных) , а затем автоматически генерировать операторы ALTER nessesary. Есть некоторые инструменты, которые могут это сделать уже, но еще не нашли хорошего.

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

1. Sqitch - perl с открытым исходным кодом; доступно для всех основных баз данных, включая PostgreSQL https://github.com/sqitchers/sqitch
2. Mahout-только для PostgreSQL; управление версиями схемы базы данных с открытым исходным кодом. https://github.com/cbbrowne/mahout
3. Liquibase-другой с открытым исходным кодом db version control sw. бесплатный версия Datical. http://www.liquibase.org/index.html
4. Datical-коммерческая версия Liquibase -https://www.datical.com/
5. Flyway by BoxFuse-коммерческий sw. https://flywaydb.org/
6. другой проект с открытым исходным кодом https://gitlab.com/depesz/Versioning Автор предоставляет руководство ЗДЕСЬ: https://www.depesz.com/2010/08/22/versioning/
7. Изменение Красных Ворот Автоматизация-только для SQL Server. https://www.red-gate.com/products/sql-development/sql-change-automation/