データベースのソース管理
データベースファイル（スクリプトなど）はソース管理上にある必要がありますか？もしそうなら、それを維持し、そこで更新する最良の方法は何ですか？
誰もが使用できる開発サーバーにデータベースファイルを配置し、必要に応じて変更できるため、データベースファイルをソース管理する必要さえありますか？しかし、誰かがそれを台無しにした場合、それを取り戻すことはできません。
ソース管理上のデータベースにはどのアプローチが最適ですか？
はい。データベースを含むソース管理からシステムの任意の部分を再構築できるはずです（また、特定の静的データについても議論します）。
それを行うためのツールが必要ない場合は、次のものを含めることをお勧めします。
- スキーマ、ユーザー、テーブル、キー、デフォルトなどの基本的なテーブル構造の作成スクリプト。
- アップグレードスクリプト（テーブル構造の変更または以前のスキーマから新しいスキーマへのデータの移行）
- ストアドプロシージャ、インデックス、ビュー、トリガー用の作成スクリプト（そこにあったものを正しい作成スクリプトで上書きするだけなので、これらのアップグレードについて心配する必要はありません）
- システムを実行するためのデータ作成スクリプト（単一のユーザー、静的な選択リストデータなど）
すべてのスクリプトには、適切なdropステートメントを含め、任意のユーザーとして実行できるように記述する必要があります（関連するスキーマ/所有者の接頭辞を含みます）。
更新/タグ付け/分岐のプロセスは、ソースコードの残りの部分とまったく同じである必要があります。データベースのバージョンをアプリケーションのバージョンに関連付けることができない場合、それを行う意味はほとんどありません。
ちなみに、テストサーバーを単に更新できると言うときは、開発サーバーを意味していると思います。開発者がオンザフライでテストサーバーを更新している場合、リリースする必要があるものを検討する際に苦痛の世界に直面しています。
はい。
それを維持し、そこで更新する最良の方法は何ですか？
ええと。スキーマビルダースクリプトを記述します。変更後、チェックインしてください。実行する前に確認してください。
何を求めているのかを判断するのは困難です。
正式なスキーマ移行スクリプトを記述します。テスト後にそれらをチェックインします。実行する前に確認してください。
もう何がありますか？
何が起こるかというと、スキーマは文書化されていない一連の変更を通じて体系的に進化するため、スキーマの変更は危険な問題に変わります。
そこにあるはずの「信頼できる」ソースがないため、この有機的な進化はスキーマの移行をより困難にします。わずかに異なる2つの製品バージョン、ステージングバージョン、QAバージョン、および8つの開発バージョンがあります。すべて少し異なります。
信頼できるソースが1つしかない場合、スキーマの移行は、前回のバージョンと今回のバージョンの差分にすぎません。
データベースのソース管理を提供することを目的とした liquibase のようなツールがあります。多くの企業が行っているように、通常のソース管理ツールで変更/更新スクリプトを維持するのは面倒であり、常に最初からデータベースを再展開することはできません。
また、データベース比較ツール（マスターと顧客のデータベースを比較）を使用してこれを自動化しようとしましたが、それは役に立ちましたが、そのようなツールを100％信頼することはできません。レビュープロセスも必要です。
はい
データベーススクリプト（ddl、dml）はコードです。 Allコードはバージョン管理システムにある必要があります。
マイグレーション
- データベースの移行を使用する
開発、qa、リリースで同じdbファイルを使用できます。
- リリース番号を使用してデータベースにリリースする
監査のためにリリース番号をどこかに保存します。多くはリリース番号をデータベース自体に保存します。各リリースは、データベースを正しいバージョンに戻す移行で構成されます。
Javaの場合、私たちのチームは Flyway を使用しています。これは非常に使いやすく強力です。
Rubyで作業している場合、Railsには Migrations があり、これもこの問題に対処する強力な方法です。
Liquibase はすでに言及されています-これは良い解決策ですが、Flywayのような他の方法よりも扱いにくいことに気付きました。
また、RedGateソフトウェアは、SQL Server用に設計された SQLソース管理 という製品を提供しています。私自身はこれを使用していませんが、同僚の1人がすばらしいと言っています。
はい
さらに、ブランチが必要です。
私はブランチにGitを使用しています：
機能ごとの開発用（アプリケーションの残りの定期的な開発のために行うように）
そして本番サーバー用に1つアプリケーションを使用する顧客もコンテンツを作成するため。
そうすることで、ソース管理と、ソースコードとデータベースの両方（および他のすべてのファイル）の分岐からメリットを得ることができます。
[PostgreSQLの場合]まだオールインワンシステムを見つけていないため、ブランチをマージするときに関数/スクリプトを適切に再インデックス付けする必要がありました（たとえば、顧客がそれらに依存しているため、運用ブランチのインデックスは変更しないでください）本番コンテンツと交差する開発ブランチからのインデックス+外部キーは再インデックス化する必要があります。これはすべてのアプリケーションで機能するわけではありませんが、アプリケーションのすべてのケースをカバーするので十分です）。
しかし、一般的な考え方はデータベースの内容はアプリケーションの重要な部分であり、すべてのリソースはソース管理にある必要があります、ergoはい、データベースにもソース管理を使用する必要があります。
開発データベースにバージョン管理や変更管理がないときに何度も目にした問題は次のとおりです。プログラマーAがテーブル、ビュー、またはプロシージャを変更します。プログラマBは同じことを変更し、プログラマAが行った内容を上書きします。または、DBAが本番DBを開発に復元し、変更を上書きします。私はこの種のものがかなりの悲しみを引き起こすのを見てきました。そして、これは開発システムでのみです。ステージング/テストを行うと、事態が非常に複雑になり、本番サーバーでさえこれに巻き込まれる可能性があります。
データベースのバージョン管理を有効にするために、通常のコードのバージョン管理と同じである必要はありません。ただし、ある種の変更管理と履歴バックアップは、多くの問題を防ぎます。
「ソース管理」ではなく「バージョン管理」と考えてください。これは、特定のスクリプトの履歴全体を確認できることを意味します。データベースを現在の形式に再構築できるかどうかは、これらのスクリプトと、スクリプトの作成に使用されるフレームワークに関する慣行の問題になります。
PHP/MySQLプロジェクトでは、 Ladder という名前の（1回限りの）小さなツールを使用しています。それは、時間の経過とともにデータベースの有機的な成長を促進するように設計されています。プロジェクトのすべての移行は、リビジョン/ソース/バージョン管理に保存され、コードとともに追跡されます。
列の追加/変更/削除、クエリの実行、インデックス、制約などの追加/削除などをサポートします。データベースの状態を追跡し、不足している移行を適用します。また、必要な移行を指定することで、「時間を遡る」こともできます。 （php ladder.php migrate 15）
ああ、そして最新の追加はデータベースの比較です。 diff-saveコマンドを使用して、データベースにいくつかの列を追加および削除し、そのdiffコマンドを実行します。データベースの状態に基づいて自動的に生成された移行コードが表示されます。
DataGrove は、ここで言及されている問題のいくつかを解決します（たとえば jfrankcarr によって）。
DBへのすべての変更を追跡し、DB全体の状態のバージョンをリポジトリに保存できます。次に、同じDBの複数の仮想コピーを生成できるため、開発者またはDBAごとに個別のコピーを作成できます（各仮想コピーを異なるバージョンから生成できます）。それは、誰かが他の人のコード/変更を上書きしないことを確認します。バーチャルコピーのそれぞれも同じリポジトリに追跡されるため、すべてのDB状態を簡単に共有および再作成できます。
また、データのバージョン管理ツールとしても使用できる監視ツールを用意したいと思います。私が話しているツールはMONyogですが、実際にはMySQLの監視ツールですが、ちょっとしたハックでデータのバージョン管理として簡単に使用できます。
しかし、先に進む前に、バージョン管理のためにデータベース全体を置くことはお勧めできないことを引用します。特定のデータセットの変更を追跡することは、本当にキラーです。
MONyogには [〜＃〜] cso [〜＃〜] （カスタムSQLオブジェクト）という機能があり、特定のデータセットの変更を監視できます。 CSOの追加について説明します ここ 。 MONyogの監視履歴セクションで、一定期間の変化を取得できます。ベスト、それはhtmlページで視覚的なレポートを提供します。レポートは次のようになります 