どうすればデータベースをgit（バージョン管理）できますか？

私はWebアプリを実行していて、いくつかの大きな変更のためにブランチを作成する必要があります。実際、これらの変更にはデータベーススキーマの変更が必要なので、データベース全体もgitの下に置きたいです。

それ、どうやったら出来るの？gitリポジトリの下に保持できる特定のフォルダはありますか？どのようにしてそれを知るのですか？正しいフォルダを配置していることをどのように確認できますか？

これらの変更には下位互換性がないため、確認する必要があります。失敗するわけにはいかない。

私の場合のデータベースはPostgreSQLです

編集：

誰かがバックアップを取り、データベースではなくバージョン管理下にバックアップファイルを置くことを提案しました。正直なところ、それを飲み込むのは本当に難しいと思います。

もっと良い方法があるはずです。

更新：

OK、それで良い方法はありませんが、まだ確信が持てないので、質問を少し変更します。

データベース全体をバージョン管理下に置きたいのですが、実際のデータベースをダンプではなくバージョン管理下に置くために、どのデータベースエンジンを使用できますか？

sqliteはgit対応ですか？

これは開発環境だけなので、好きなデータベースを選択できます。

Edit2：

私が本当に望んでいるのは、私の開発履歴を追跡するのではなく、「新しい根本的な変更」ブランチから「現在の安定ブランチ」に切り替えて、たとえば現在のバグ/問題などを修正できるようにすることです安定したブランチ。ブランチを切り替えると、データベースが自動的に現在のブランチと互換性を持つようになります。実際のデータはあまり気にしません。

代わりにデータベースダンプを取り、バージョン管理します。このように、それはフラットテキストファイルです。

個人的には、データダンプとスキーマダンプの両方を保持することをお勧めします。このようにdiffを使用すると、スキーマのリビジョン間での変更点を簡単に確認できます。

大きな変更を行う場合は、ブランチを作成しているので、新しいスキーマに変更を加え、古いデータベースには触れないセカンダリデータベースが必要です。

コードの変更と並行してデータベースを維持するための一連の優れた手法については、データベースのリファクタリング（http://databaserefactoring.com/）を確認してください。

あなたが間違った質問をしていると言うだけで十分です。データベースをgitに置く代わりに、変更を小さな検証可能なステップに分解して、スキーマの変更を簡単に移行/ロールバックできるようにする必要があります。

完全な回復性が必要な場合は、postgres WALログをアーカイブし、PITR（ポイントインタイムリカバリ）を使用して、特定の既知の良好な状態にトランザクションを再生/転送する必要があります。

私は本当に簡単な解決策を考え始めています、なぜ私が以前にそれを考えなかったのか分かりません!!

• データベースを複製します（スキーマとデータの両方）。
• new-major-changesのブランチで、プロジェクトの構成を変更して、新しい複製データベースを使用します。

これにより、データベーススキーマの変更を気にすることなくブランチを切り替えることができます。

編集：

複製とは、別の名前（などmy_db_2）で別のデータベースを作成することを意味します。ダンプなどはしていません。

LiquiBaseのようなものを使用すると、Liquibaseファイルのリビジョン管理を維持できます。プロダクションのみの変更にタグを付けることができ、プロダクションまたは開発（または任意のスキーム）でDBを最新の状態に保つことができます。

同様のニーズに直面し、データベースバージョン管理システムに関する私の研究が投げかけたものは次のとおりです。

1. Sqitch-perlベースのオープンソース。PostgreSQLを含むすべての主要なデータベースで利用可能 https://github.com/sqitchers/sqitch
2. Mahout-PostgreSQLのみ。オープンソースのデータベーススキーマのバージョン管理。 https://github.com/cbbrowne/mahout
3. Liquibase-別のオープンソースデータベースバージョンコントロールソフトウェア。ダティカルの無料版。http://www.liquibase.org/index.html
4. Datical-Liquibaseの商用バージョン-https : //www.datical.com/
5. BoxFuseによるFlyway-コマーシャルsw。https://flywaydb.org/
6. 別のオープンソースプロジェクトhttps://gitlab.com/depesz/Versioning Authorがここでガイドを提供しています。 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/

この目的のためだけに構築された、Doctrineの下のMigrationsという素晴らしいプロジェクトがあります。

まだアルファ状態で、php用にビルドされています。

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

私は、DBベースのディレクトリ構造に似た何かが「ファイル」を格納し、それを管理するためにgitを必要とする同様の問題があるので、この質問に遭遇しました。レプリケーションを使用してクラウド全体に分散されているため、アクセスポイントはMySQLを経由します。

上記の回答の要点は、Gitを使用してデータベース内の何かを管理するという、求められている問題の別の解決策を同様に提案しているように思われるので、その質問に答えてみます。

Gitはシステムであり、基本的には、デルタ（差分）のデータベースを格納します。これは、コンテキストを再現するために再構成できます。gitの通常の使用では、コンテキストがファイルシステムであり、それらのデルタはそのファイルシステム内のdiffであると想定していますが、実際にはすべてのgitは、デルタの階層データベースです（ほとんどの場合、各デルタは少なくとも1つのコミットなので親、ツリーに配置）。

理論的には、デルタを生成できる限り、gitはそれを格納できます。問題は通常、gitがデルタを生成しているコンテキストがファイルシステムであることを想定していることです。同様に、git階層内のポイントをチェックアウトすると、ファイルシステムが生成されることを想定しています。

変更をデータベースで管理したい場合、2つの個別の問題があり、私はそれらに個別に対処します（私があなただった場合）。1つ目はスキーマ、2つ目はデータです（ただし、質問では、データは問題ではないと述べています）。私が過去に抱えていた問題は、DevとProdデータベースでした。Devはスキーマに増分変更を加えることができ、それらの変更はCVSで文書化され、ライブに伝達され、いくつかの「静的」の1つに追加されました。テーブル。これを行うには、静的データのみを含むCruiseと呼ばれる3番目のデータベースを使用しました。どの時点でも、DevとCruiseのスキーマを比較でき、これら2つのファイルの差分を取得して、ALTERステートメントを含むSQLファイルを生成し、適用するスクリプトがありました。同様に、新しいデータ、INSERTコマンドを含むSQLファイルに抽出できます。フィールドとテーブルが追加されるだけで、削除されない限り、プロセスはSQLステートメントの生成を自動化してデルタを適用できます。

gitがデルタを生成diffするメカニズムはgitであり、1つ以上のデルタをファイルと組み合わせるメカニズムはと呼ばれmergeます。異なるコンテキストからの差分とマージの方法を思い付くことができれば、gitは機能するはずですが、すでに説明したように、それを行うツールを好むかもしれません。それを解決するための私の最初の考えはこれです https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Toolsこれはgitの内部差分を置き換える方法と、マージツール。問題のより良い解決策を見つけたときに、この回答を更新しますが、私の場合は、DBベースのファイルストアが変更される可能性がある限り、データ変更のみを管理する必要があると予想しているため、私の解決策正確にあなたが必要とするものではないかもしれません。

RedGate SQLソース管理を見てください。

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

このツールはSQL Server Management Studioスナップインであり、Gitを使用してデータベースをソース管理下に置くことができます。

ユーザーあたり495ドルとやや高価ですが、28日間の無料試用が利用できます。

注私は、いかなる方法でもRedGateとは提携していません。

同様のことをしたいのですが、データベースの変更をバージョン管理システムに追加します。

この投稿のウラジミール・ホリコフの「データベースのバージョニングのベストプラクティス」のアイデアに従います。要約すると、私は

• スキーマと参照データの両方をソース管理システムに保存します。
• すべての変更について、変更を含む個別のSQLスクリプトを作成します

それが役立つ場合！

• アーミン
• Flur.ee
• Crux DB

私はしばらくの間、Postgres（または一般にSQLデータベース）に同じ機能を探していましたが、十分に適した（シンプルで直感的な）ツールは見つかりませんでした。これはおそらく、データの格納方法がバイナリであることが原因です。クロニオは理想的に聞こえますが死んでいるように見えます。Noms DBは興味深く見えます（そして生きています）。また、Irmin（OCamlベース、Gitプロパティ付き）もご覧ください。

これはPostgresで動作するという質問には答えませんが、Flur.eeデータベースをチェックしてください。これには、任意の時点からデータを照会できる「タイムトラベル」機能があります。「分岐」モデルで機能するはずです。

このデータベースは最近、ブロックチェーンの目的で開発されました。ブロックチェーンの性質上、データは増分で記録する必要があります。これはgitの動作とまったく同じです。彼らはされているQ2 2019年のオープンソースリリースをターゲットに。

各Flureeデータベースはブロックチェーンであるため、実行されたすべてのトランザクションの履歴全体が保存されます。これは、情報が不変で安全であることをブロックチェーンが保証する方法の一部です。

更新：挿入の時間ディメンション全体を照会できるCruxデータベースもチェックしてください。これは「バージョン」として表示されます。Cruxは、高く評価されたDatomicのオープンソース実装のようです。

Cruxは、トランザクション時間と有効な時間履歴を格納するバイテンポラルデータベースです。[ユニ]テンポラルデータベースは、データベース作成の瞬間から現在の状態までの一連のトランザクションステートを介した「タイムトラベル」クエリを可能にしますが、Cruxは不必要な設計の複雑さや不要な個別の有効時間軸の「タイムトラベル」クエリも提供します。パフォーマンスへの影響。つまり、Cruxユーザーは、情報の到着順序に関係なく、データベースに過去および将来の情報を入力し、過去の記録を修正して、特定のドメインの絶えず改善される時間モデルを構築できます。

アトミック性なくしてそれを行うことはできません。また、pg_dumpまたはスナップショットファイルシステムを使用せずにアトミック性を得ることはできません。

私のpostgresインスタンスはzfsにあり、時々スナップショットを撮ります。ほぼ瞬時で一貫しています。

精神的に望むのは、おそらくデータベースのバージョンをデータベースに格納するPost Factoのようなものでしょう。このプレゼンテーションを確認してください。

このプロジェクトは実際にはどこにも行ったことがないため、おそらくすぐには役に立たないかもしれませんが、興味深いコンセプトです。これを正しく行うのは非常に難しいのではないかと心配しています。バージョン1でさえ、人々に信頼してもらうためにすべての詳細を正しく取得する必要があるからです。

私はあなたが求めていることをするsqlite用のツールをリリースしました。sqliteプロジェクトツール 'sqldiff'、UUIDを主キーとして活用するカスタムdiffドライバーを使用し、sqliteのROWIDは省略します。まだアルファ版なので、フィードバックを歓迎します。

Postgresとmysqlは、バイナリデータが複数のファイルに保存されており、スナップショットを作成できたとしても有効ではない可能性があるため、トリッキーです。

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

X-Istenceは順調に進んでいると思いますが、この戦略にできる改善点がいくつかあります。まず、以下を使用します。

$pg_dump --schema ... 

テーブル、シーケンスなどをダンプし、このファイルをバージョン管理下に置きます。これを使用して、ブランチ間の互換性の変更を分離します。

次に、フォームのデフォルトやユーザーが変更できないその他のデータなど、アプリケーションが動作するために必要な構成（ユーザーデータなどをスキップする必要がある）を含むテーブルセットのデータダンプを実行します。これを選択的に行うには、以下を使用します。

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

完全なデータダンプを実行するときにデータベースが100Mb +に達すると、リポジトリが非常に扱いにくくなる可能性があるため、これは良い考えです。アプリをテストするために必要な最小限のデータセットをバックアップすることをお勧めします。ただし、デフォルトのデータが非常に大きい場合でも、問題が発生する可能性があります。

完全バックアップをリポジトリに配置する必要がある場合は、ソースツリー外のブランチで実行することを検討してください。ただし、一致するsvn revへの参照がある外部バックアップシステムがこれに最適です。

また、（少なくともスキーマについては）リビジョンの目的でバイナリよりもテキスト形式のダンプを使用することをお勧めします。チェックインする前に、常にこれらを圧縮してスペースを節約できます。

最後に、まだ行っていない場合は、postgresバックアップドキュメントを参照してください。ダンプではなく「データベース」のバックアップについてコメントしていると、ファイルシステムベースのバックアップを考えているのではないかと思います（警告については、セクション23.2を参照）。

この質問にはかなりの回答がありますが、X-Istenceの回答とDana the Saneの回答を少し提案して補足したいと思います。

ある程度細かい、たとえば毎日のリビジョン管理が必要な場合は、テーブルとスキーマの両方のテキストダンプをrdiff-backupなどのツールで結合できます。は、増分バックアップを行うます。利点は、毎日のバックアップのスナップショットを保存する代わりに、前日の差分を保存するだけです。

これにより、リビジョン管理の利点とスペースを無駄にしないことの両方が得られます。

いずれにせよ、頻繁に変更される大きなフラットファイルに対して直接gitを使用することは良い解決策ではありません。データベースが大きくなりすぎると、gitでファイルの管理に問題が発生し始めます。

これが私が私のプロジェクトでやろうとしていることです：

• 個別のデータとスキーマ、およびデフォルトのデータ。

データベース構成は、バージョン管理されていない構成ファイル（.gitignore）に保存されます

データベースのデフォルト（新しいプロジェクトを設定するため）は、バージョン管理された単純なSQLファイルです。

データベーススキーマについては、バージョン管理下でデータベーススキーマダンプを作成します。

最も一般的な方法は、SQLステートメントを含む更新スクリプトを使用することです（ALTER Table ..またはUPDATE）。また、スキーマの現在のバージョンを保存するデータベース内の場所も必要です）

他の大きなオープンソースデータベースプロジェクト（piwik、またはお気に入りのcmsシステム）を見てください。これらはすべてupdatescripts（1.sql、2.sql、3.sh、4.php.5.sql）を使用しています。

しかし、これは非常に時間のかかる作業であり、更新スクリプトを作成してテストする必要があり、バージョンを比較して必要なすべての更新スクリプトを実行する共通の更新スクリプトを実行する必要があります。

したがって、理論的には（そしてそれが私が探しているものです）、変更ごとにデータベーススキーマをダンプすることができます（手動で、conjob、gitフック（おそらくコミット前））（そして、非常に特殊な場合にのみ、更新スクリプトを作成します）

その後、共通のupdatescriptで（特別な場合は通常のupdatescriptを実行します）、スキーマ（ダンプと現在のデータベース）を比較して、必要なALTERステートメントを自動的に生成します。既にこれを行うことができるツールがいくつかありますが、まだ良いツールが見つかりません。

データベースのバージョン管理にはneXtepをお勧めします。これには、インストール方法と発生したエラーを説明する一連の優れたドキュメントとフォーラムがあります。私はそれをpostgreSQL 9.1および9.3でテストしましたが、9.1で動作させることができましたが、9.3では動作しないようです。

私の個人的なプロジェクトでは、データベース全体をDropboxに保存し、MAMP、WAMPワークフローをポイントして、そこからすぐに使用できるようにします。このようにして、データベースは常に最新の状態になり、開発を行う必要があります。しかし、それは開発者向けです！ライブサイトはもちろん、独自のサーバーを使用しています！:)

gitバージョン管理下でデータベース変更の各レベルを保存することは、コミットごとにデータベース全体をプッシュし、プルするたびにデータベース全体を復元するようなものです。データベースが非常に重要な変化に非常になりやすいですし、それらを失うわけにはいかないことができれば、あなたは自分の更新ができpre_commitとpost_mergeフックを。私は自分のプロジェクトの1つで同じことをしました。

それが私のやり方です：

DBタイプについては自由に選択できるため、firebirdなどのファイルベースのDBを使用してください。

実際のブランチに適合するスキーマを持つテンプレートDBを作成し、リポジトリに保存します。

アプリケーションを実行してプログラムでテンプレートDBのコピーを作成し、それを別の場所に保存して、そのコピーを操作します。

このようにして、データなしでDBスキーマをバージョン管理下に置くことができます。スキーマを変更する場合は、テンプレートDBを変更するだけです

以前は、標準のLAMP構成でソーシャルWebサイトを実行していました。ライブサーバー、テストサーバー、開発サーバー、およびローカルの開発者マシンがありました。すべてGITを使用して管理されていました。

各マシンには、PHPファイルだけでなく、MySQLサービスと、ユーザーがアップロードする画像を含むフォルダーも用意されていました。Liveサーバーのユーザー数が100K（！）に増え、ダンプは約2GB（！）、Imageフォルダーは約50GB（！）でした。私が去ったとき、サーバーはCPU、Ram、そして何よりも同時接続数の制限に達していました（サーバーを最大化するために、独自のバージョンのネットワークカードドライバーをコンパイルしました）。GITに2GBのデータと50GBの画像を配置することはできませんでした（あなたのWebサイトで想定してはいけません）。

これらすべてをGITで簡単に管理するには、これらのフォルダーパスを.gitignoreに挿入して、バイナリフォルダー（画像を含むフォルダー）を無視します。また、Apacheのdocumentrootパスの外側にSQLというフォルダもありました。そのSQLフォルダーに、開発者からのSQLファイルを番号を付けて追加します（001.florianm.sql、001.johns.sql、002.florianm.sqlなど）。これらのSQLファイルもGITによって管理されました。最初のsqlファイルには、実際には大量のDBスキーマが含まれます。GITにユーザーデータ（ユーザーテーブルのレコードやコメントテーブルなど）を追加することはありませんが、構成やトポロジ、その他のサイト固有のデータなどのデータは、SQLファイルで（したがってGITによって）維持されていました。ほとんどの場合、SQLスキーマとデータに関してGITによって何が保守されていないかを決定する開発者（コードを最もよく知っている開発者）です。

リリースに到達すると、管理者は開発サーバーにログインし、ライブブランチをすべての開発者とマージし、開発マシンの必要なブランチを更新ブランチにマージして、テストサーバーにプッシュします。テストサーバーで、ライブサーバーの更新プロセスがまだ有効かどうかを確認し、続けてApacheのすべてのトラフィックをプレースホルダーサイトにポイントし、DBダンプを作成し、作業ディレクトリを「ライブ」から「更新」にポイントします。 '、すべての新しいsqlファイルをmysqlに実行し、トラフィックを正しいサイトに再ポイントします。テストサーバーを確認した後、すべての関係者が同意すると、管理者はテストサーバーからライブサーバーに同じことを行いました。その後、本番サーバーのライブブランチをすべてのサーバーのマスターブランチにマージし、すべてのライブブランチをリベースしました。

テストサーバーに問題があった場合。マージで競合が多すぎたため、コードが元に戻され（作業中のブランチが「ライブ」に戻っていることを示しています）、SQLファイルは実行されませんでした。SQLファイルが実行された瞬間、これはその時点では元に戻せないアクションと見なされていました。SQLファイルが適切に機能していなかった場合、ダンプを使用してDBが復元されました（開発者は、十分にテストされていないSQLファイルを提供したことを通知しました）。

今日、私たちはsql-upフォルダーとsql-downフォルダーの両方を同等のファイル名で維持しています。開発者は、両方のアップグレードsqlファイルを同等にダウングレードできることをテストする必要があります。これは最終的にbashスクリプトを使用して実行できますが、人間の目がアップグレードプロセスを監視し続けている場合は、この方法をお勧めします。

それは素晴らしいことではありませんが、扱いやすいです。これにより、実際の実用的な比較的可用性の高いサイトへの洞察が得られることを願っています。それは少し時代遅れですが、まだ続いています。

データベース自体ではなく、プロジェクトのライフサイクル全体にわたってデータベースに加えた変更をバージョン管理できるようにするiBatis Migrations（手動、短いチュートリアルビデオ）などのツールを使用します。

これにより、個々の変更を異なる環境に選択的に適用したり、どの環境にどの変更があったかを変更ログに記録したり、変更A〜Nを適用するスクリプトを作成したり、変更をロールバックしたりできます。

データベース全体をバージョン管理下に置きたいのですが、実際のデータベースをダンプではなくバージョン管理下に置くために、どのデータベースエンジンを使用できますか？

これはデータベースエンジンに依存しません。Microsoft SQL Serverでは、バージョン管理プログラムが多数あります。この問題はgitでは解決できないと思います。pgsql固有のスキーマバージョン管理システムを使用する必要があります。そんなものが存在するかどうかはわかりませんが...

2019年8月26日更新：

Netlify CMSはGitHubを使用して実行しています。実装例は、netlify-cms-backend-githubの実装方法に関するすべての情報とともにここにあります。