データベースファイル（スクリプトなど）をソース管理する必要がありますか？もしそうなら、それをそこに保持し、そこで更新する最良の方法は何ですか？

データベースファイルをソース管理する必要もあります。開発サーバーに配置して、誰でも使用でき、必要に応じて変更を加えることができるからです。しかし、その後、誰かがそれを台無しにした場合、それを取り戻すことはできません。

ソース管理上のデータベースに最適なアプローチは何ですか？

はい。データベースを含むソース管理からシステムの任意の部分を再構築できるはずです（また、特定の静的データについても議論します）。

あなたがそれを行うためのツールを持ちたくないと仮定すると、私はあなたが以下を含めたいと思うことを提案します：

• スキーマ、ユーザー、テーブル、キー、デフォルトなどを含む基本的なテーブル構造の作成スクリプト。
• アップグレードスクリプト（テーブル構造の変更または以前のスキーマから新しいスキーマへのデータの移行）
• ストアドプロシージャ、インデックス、ビュー、トリガーの作成スクリプト（そこにあったものを正しい作成スクリプトで上書きするだけなので、これらのアップグレードについて心配する必要はありません）
• システムを実行するためのデータ作成スクリプト（単一のユーザー、静的な選択リストデータなど）

すべてのスクリプトには、適切なドロップステートメントが含まれ、任意のユーザーとして実行できるように記述される必要があります（関連するスキーマ/所有者プレフィックスを含む場合）。

更新/タグ付け/分岐のプロセスは、ソースコードの残りの部分とまったく同じである必要があります。データベースバージョンをアプリケーションバージョンに関連付けることができない場合、それを行う意味はほとんどありません。

ちなみに、テストサーバーを更新するだけでいいと言うときは、開発サーバーを意味します。開発者がテストサーバーをオンザフライで更新している場合、リリースする必要があるものを解決することに苦痛の世界を見ています。

はい。

それを維持し、そこで更新する最良の方法は何ですか？

あの スキーマビルダースクリプトを記述します。変更を加えてからチェックインします。実行する前に確認してください。

何を求めているのかを判断するのは困難です。

正式なスキーマ移行スクリプトを作成します。テスト後にそれらをチェックインします。実行する前に確認してください。

他に何がありますか？

何が起こるかというと、スキーマは文書化されていない一連の変更を通じて有機的に進化するため、スキーマの変更は危険な問題に変わります。

この有機的な進化により、スキーマの移行はより困難になります。なぜなら、そこにあるはずの「信頼できる」ソースがないからです。ステージングバージョン、QAバージョン、8つの開発バージョンという、わずかに異なる2つの製品バージョンがあります。すべてわずかに異なります。

信頼できる単一のソースが1つあった場合、スキーマの移行は、最後のバージョンとこのバージョンの単なる差分になります。

はい

データベーススクリプト（ddl、dml）はコードです。 すべてのコードはバージョン管理システム内にある必要があります。

移行

• データベースの移行を使用する

開発、qaおよびリリースで同じdbファイルを使用できます。

• リリース番号付きのデータベースへのリリース

監査のためにリリース番号をどこかに保存します。多くはデータベース自体に保存します。各リリースは、データベースを正しいバージョンに移行する移行で構成されます。

データベースのソース管理を提供するためのliquibaseなどのツールがあります。多くの企業が行うように、通常のソース管理ツールで変更/更新スクリプトを維持するのは面倒であり、データベースを常にゼロから再デプロイすることはできません。

データベース比較ツール（マスターデータベースと顧客データベースの比較）でこれを自動化することも試みましたが、それは役立ちましたが、そのようなツールを100％信頼することはできません。間違いなくレビュープロセスも必要です。

はい

さらに、ブランチが必要になります。

ブランチにGitを使用します。

• 機能ごとの開発用（アプリケーションの他の部分の定期的な開発の場合と同様）

• また、アプリケーションを使用する顧客もコンテンツを作成するため、実動サーバー用にも1つです。

そうすれば、ソースコードとデータベース（およびその他のファイル）の両方について、ソース管理と分岐の利点を得ることができます。

私はまだ[PostgreSQLの]オールインワンシステムを見つけていないので、ブランチをマージするときに適切にインデックスを再作成する関数/スクリプトを作成する必要がありました（たとえば、本番ブランチのインデックスは、本番コンテンツと交差する開発ブランチからのインデックス+外部キーは、インデックスを再作成する必要があります。すべてのアプリケーションで機能するわけではありませんが、アプリケーションのすべてのケースをカバーするので十分です。

しかし、一般的な考え方は、データベースの内容はアプリケーションの重要な部分であり、すべてのリソースはソース管理にあるべきだということです。そう、データベースにもソース管理を使用する必要があります。

Javaの場合、私たちのチームはFlywayを使用します。これは非常に使いやすく強力です。

Rubyで作業している場合、RailsにはMigrationsがあり、これもこの問題に対処する強力な方法です。

Liquibaseはすでに言及されています-それは良い解決策ですが、Flywayのような代替案よりも扱いにくいと感じました。

また、RedGateソフトウェアは、SQL Server用に設計されたSQL Source Controlと呼ばれる製品を提供します。私は自分で使ったことはありませんが、同僚の一人がそれは素晴らしいと言っています。

ここに、開発データベースにバージョン管理や変更管理がないときに何度も見た問題があります。プログラマAは、テーブル、ビュー、またはプロシージャに変更を加えます。プログラマーBは同じことを変更し、プログラマーAが行ったことを上書きします。または、DBAは本番DBを開発に復元し、変更を上書きします。私はこの種のものがかなりの悲しみを引き起こすのを見てきました。そして、これは開発システムでのみです。ステージング/テスト、さらには実稼働サーバーでさえこれに追いつくと、物事は本当に面倒になります。

データベースのバージョン管理を有効にするために、通常のコードバージョン管理と同じである必要はありません。ただし、ある種の変更管理と履歴のバックアップにより、多くの問題を防ぐことができます。

「ソース管理」ではなく「バージョン管理」と考えてください。これは、その特定のスクリプトの履歴全体を表示できることを意味します。データベースを現在の形式に再構築できるかどうかは、これらのスクリプトとそれらを作成するために使用されるフレームワークに関するあなたの慣習の問題になるでしょう。

PHP / MySQLプロジェクトでは、（1回）Ladderという名前の小さなツールを使用しています。時間の経過とともにデータベースの有機的な成長を促進するように設計されています。プロジェクトのすべての移行は、リビジョン/ソース/バージョン管理に保存され、コードとともに追跡されます。

列の追加/変更/削除、クエリの実行、インデックス、制約などの追加/削除などをサポートします。データベースの状態を追跡し、不足している移行を適用します。また、必要な移行を指定することにより、「過去に戻る」こともできます。（php ladder.php migrate 15）

ああ、最新の追加はデータベースの差分化です。diff-saveコマンドを実行し、データベースにいくつかの列を追加および削除して、diffコマンドを実行します。データベースの状態に基づいて自動的に生成された移行コードが表示されます。

DataGroveは、ここで説明した問題のいくつかを解決します（たとえばjfrankcarrによる）。

DBへのすべての変更を追跡し、DB全体の状態のバージョンをリポジトリに保存できます。その後、同じDBの複数の仮想コピーを生成できるため、各開発者またはDBAは独自のコピーを所有できます（各仮想コピーは異なるバージョンから生成できます）。誰かが他の人のコード/変更を上書きしないようにします。各バーチャルコピーも同じリポジトリに追跡されるため、すべてのDBの状態を簡単に共有および再作成できます。

また、データバージョン管理ツールとしても使用できる監視ツールを提供したいと思います。私が話しているツールはMONyogで、実際にはMySQL監視ツールですが、ちょっとしたハックで簡単にデータのバージョン管理として使用できます。

しかし、先に進む前に、データベース全体をバージョニング用に配置することはお勧めできません。特定のデータセットの変更を追跡するのは本当に重要です。

MONyogには、特定のデータセットの変更を監視できるCSO（カスタムSQLオブジェクト）と呼ばれる機能があります。CSOの追加については、ここで説明します。MONyogのモニター履歴セクションでは、一定期間の変更を取得できます。最良の方法は、HTMLページで視覚的なレポートを提供することです。レポートは次のようになります