ウェブサイトの開発/生産段階でデータベースをどうしますか？
しばらくの間、標準の開発/生産段階で開発しているWebサイトを維持しています。それは非常に単純です：開発者向けのMercurialリポジトリ、本番用のリポジトリ。開発者で作業し、承認され、本番環境にプッシュします。
しかし今、私はこのプロセスをデータベースを持つ新しいウェブサイトに適用しようとしており、開発戦略を理解する方法に苦労しています。上記で言及しなかったのは、すべての作業を自分のリポジトリで行い、それを開発者にプッシュし、その後本番にプッシュするため、3つの異なるサーバーです。では、どのようにデータベースを管理しますか？
コミットごとのmysqldumpの明らかな解決策は発生しません。また、一日の終わりに行われたダンプは、その日の途中で発生した1つの変更を後で取り消す場合にはあまり役に立ちません。
これを達成する最良の方法は何ですか？
ソリューションは、実際に使用するデータベースに依存する場合があります。
ただし、一般的には、3つのサーバー（dev、test、prod）を保持し、構造体ダンプをデータダンプとは別に動作させます。生成されたSQLファイルを通じて、構造のバージョン管理を追跡できます。
さて、私はこのプロセスが多くの中規模/大規模プロジェクトで使用されているようで、お勧めします。
ほとんどのリビジョン管理システムは、ソース管理用に設計されています。バイナリデータやデータベースなど、他の種類のデータをバージョン管理するようには設計されていません。
ほとんどの場合、実際にデータをバージョン管理する理由はありません。とにかく開発用ではありません。一般に、ソースコードは特定のデータ状態に依存するべきではありません。
通常、バージョン管理されているのはスキーマ（およびストアドプロシージャ）です。また、これを意味のある方法で実行できる唯一の方法は、差分エンジンに完全なDDLパーサーを含めることであるため、リビジョン管理システムは通常、使用しているデータモデリングソフトウェアに関連付けられています。
しかし、そのタイプのソフトウェアは非常に高価になる可能性があるため、 その他のオプション もあります。たとえば、スキーマダンプまたはデータベース作成/初期化スクリプトを単純にバージョン管理できます。または、アップグレードスクリプトを手動で記述して、データベースのあるバージョンから別のバージョンにアップグレードすることもできます。これは苦痛になる可能性がありますが、そのため、最初からデータモデルを正しくしようとする必要があります。データベーススキーマをあるリビジョンから次のリビジョンに絶えず変更している場合、おそらく何か間違ったことをしていることになります。
データについては、通常、テストデータをCSVファイルなどに個別に保存します。また、通常、アプリケーションを介して自動的にインポートでき、アプリケーションが使用しているデータベーススキーマへの変換プロセスを処理します。