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

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

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

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

База данных в моем случае это PostgreSQL

Редактировать:

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

Там должен быть лучший способ.

Обновить:

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

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

Будет ли sqlite дружелюбным?

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

Edit2:

Что я действительно хочу, так это не отслеживать мою историю разработки, а иметь возможность переключаться с моей ветки «новые радикальные изменения» на «текущую стабильную ветку» и, например, иметь возможность исправлять некоторые ошибки / проблемы и т. Д. С текущей стабильная ветка. Таким образом, когда я переключаю ветки, база автоматически становится совместимой с веткой, на которой я сейчас работаю. Меня не особо волнуют фактические данные.

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ:

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

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

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

1. Sqitch - открытый исходный код на основе Perl; доступно для всех основных баз данных, включая PostgreSQL https://github.com/sqitchers/sqitch
2. Mahout - только для PostgreSQL; контроль версий схемы базы данных с открытым исходным кодом. https://github.com/cbbrowne/mahout
3. Liquibase - еще один с открытым исходным кодом управления версиями 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. Red Gate Change Automation - только для SQL Server. https://www.red-gate.com/products/sql-development/sql-change-automation/

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

Это все еще в альфа-состоянии и построен для PHP.

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

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

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

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

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

Если вы хотите управлять изменениями в базе данных, у вас есть две отдельные проблемы, и я бы решил их отдельно (на вашем месте). Первый - это схема, второй - данные (хотя в вашем вопросе вы заявляете, что данные вас не беспокоят). В прошлом у меня была проблема с базой данных Dev и Prod, где Dev мог вносить пошаговые изменения в схему, и эти изменения должны были документироваться в CVS и распространяться на них, наряду с дополнениями к одному из нескольких «статических». столы. Мы сделали это, имея третью базу данных под названием Cruise, которая содержала только статические данные. В любой момент можно было сравнить схему из Dev и Cruise, и у нас был сценарий, чтобы взять разность этих двух файлов и создать файл 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 и инструмент слияния. Я обновлю этот ответ, так как я придумаю лучшее решение проблемы, но в моем случае я ожидаю, что мне придется только управлять изменениями данных, поскольку база данных на базе БД может измениться, поэтому мое решение может быть не совсем то, что вам нужно.

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

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

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

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

ПРИМЕЧАНИЕ. Я никоим образом не связан с RedGate.

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

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

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

На случай, если это поможет!

• Irmin
• Flur.ee
• Crux DB

Некоторое время я искал ту же функцию для Postgres (или баз данных SQL в целом), но не нашел подходящих инструментов (простых и интуитивно понятных). Вероятно, это связано с бинарным характером хранения данных. Клонио звучит идеально, но выглядит мертвым. Номс БД выглядит интересно ( и живо ). Также взгляните на Irmin (на основе OCaml с Git-свойствами).

Хотя это не дает ответа на вопрос о том, что он будет работать с Postgres, проверьте базу данных Flur.ee. Он имеет функцию «путешествия во времени», которая позволяет запрашивать данные с произвольного момента времени. Я предполагаю, что это должно быть в состоянии работать с "ветвящейся" моделью.

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

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

Обновление : также ознакомьтесь с базой данных Crux , которая может выполнять запросы во временном измерении вставок, которые вы можете видеть как «версии». Crux, кажется, является реализацией с открытым исходным кодом высоко оцененной Datomic.

Crux - это битемпоральная база данных, которая хранит время транзакций и действительные истории времени. В то время как временная база данных [uni] позволяет выполнять запросы «путешествия во времени» через транзакционную последовательность состояний базы данных с момента создания базы данных до ее текущего состояния, Crux также обеспечивает запросы «путешествия во времени» для дискретной действительной оси времени без ненужной сложности проектирования или влияние на производительность. Это означает, что пользователь Crux может заполнить базу данных прошлой и будущей информацией независимо от того, в каком порядке она поступает, и внести исправления в прошлые записи, чтобы построить постоянно улучшающуюся временную модель данного домена.

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

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

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

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

Я выпустил инструмент для sqlite, который делает то, что вы просите. Он использует собственный драйвер diff, использующий инструмент проектов sqlite «sqldiff», UUID в качестве первичных ключей, и исключает rowl rowid. Это все еще в альфа-версии, поэтому обратная связь приветствуется.

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

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

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

$pg_dump --schema ... 

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

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

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

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

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

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

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

На этот вопрос довольно много ответов, но я хотел бы дополнить ответ X-Istence и Dana the Sane небольшим предложением.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На каждой машине у нас были файлы PHP, а также служба MySQL и папка с изображениями, которые пользователи могли загружать. На сервере Live выросло около 100 КБ (!) Повторных пользователей, дамп был около 2 ГБ (!), Папка «Образ» - около 50 ГБ (!). К тому времени, когда я ушел, наш сервер достиг предела своего ЦП, Ram, и, самое главное, ограничения одновременных сетевых соединений (мы даже скомпилировали нашу собственную версию драйвера сетевой карты, чтобы максимально использовать сервер 'lol'). Мы не могли ( и вы не должны предполагать на своем сайте ) поместить 2 ГБ данных и 50 ГБ изображений в GIT.

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

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

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

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

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

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

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

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

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

Обновление 26 августа 2019 года:

Netlify CMS делает это с GitHub, пример реализации можно найти здесь со всей информацией о том, как они реализовали это netlify-cms-backend-github

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