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

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

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

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

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

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

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

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

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

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

Есть отличный проект под названием Migrations under Doctrine, созданный специально для этой цели.

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

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

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

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

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

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

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

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

• Irmin (ветвление + путешествие во времени)
• Flur.ee (неизменяемый + путешествие во времени)
• Crux DB (путешествия во времени)
• TerminusDB (ветвление + путешествие во времени)
• DoltDB (ветвление + путешествие во времени)

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

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

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

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

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

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

Обновление II. Ознакомьтесь с Terminus DB: документацией для TerminusDB - графической базы данных с открытым исходным кодом, в которой хранятся данные, подобные git. Он поддерживает ветвление, как Dolt и Git, но пока не выглядит очень зрелым.

Обновление III NomsDB был разветвлен и теперь используется в DoltDB: https://github.com/dolthub/dolt

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

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

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

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

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

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

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

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

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

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

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

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

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

Я выпустил инструмент для sqlite, который делает то, о чем вы просите. Он использует настраиваемый драйвер diff, использующий инструмент проектов sqlite sqldiff, UUID в качестве первичных ключей и исключает sqlite 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)

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

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

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

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

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

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

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

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

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

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

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

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

На каждой машине у нас были файлы PHP, а также служба MySQL и папка с изображениями, которые пользователи загружали. Live-сервер вырос до 100К (!) Постоянных пользователей, дамп был около 2ГБ (!), Папка с изображениями была около 50ГБ (!). К тому времени, когда я ушел, наш сервер достиг предела своего ЦП, ОЗУ и, прежде всего, пределов одновременных сетевых подключений (мы даже скомпилировали нашу собственную версию драйвера сетевой карты, чтобы максимально использовать сервер '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.

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

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

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

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

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

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

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

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

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

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

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