0

目標は、任意の2つの時点でスキーマに変更が加えられたため、テーブルを変更/更新するための簡潔なSQLスクリプトを作成することです。

たとえば、1台のマシンで開発し、「A」日目に、ダンプおよび復元ユーティリティを使用して、本番マシンにデータベースをインストールしました。次に、開発マシンでいくつかの変更を加えてテストした後の「B」日目に、スキーマへの変更を本番サーバーに取り込む必要があります。

スキーマに対して行うすべてのコマンド(一部は実験的で元に戻されている可能性があります)を作成する以外に、スキーマをポイントAからポイントB(またはポイントBからポイントF)にアップグレードするための適切な方法は何ですか?

アップデート:

データベースのdiffのような概念は、正当な理由で非常に眉をひそめているようです。だから、これは私に新しい質問を残します。

  1. 実験的な変更と生産に値する変更を明確に管理するための簡単な方法は何ですか?不利なことをしたときに、開発データベースを最後の既知の良好な状態に復元し続けますか?

  2. 更新スクリプトとして使用されるように引き出すことができる方法ですべてのアクションをログに記録するようにpostgresqlを構成できますか?私が尋ねる理由は、私がPgAdminIIIでの作業を楽しんでいるからです。私は、構築や実験用の更新スクリプトを作成するよりも、それを使用して作業したいと思っています。

4

1 に答える 1

3

スキーマに作成するすべてのコマンドを記述することはできません

制御された「プロフェッショナルな」方法でそれを行いたい場合は、それを回避する方法はありません. これらの移行スクリプトを整理して実行するには、スキーマ管理ツールの使用を検討する必要があります。

Liquibase での経験は非常に優れています。Oracle、DB2、および PostgreSQL での移行に使用します。

Postgres 固有のソリューションについては、Sqitchを参照してください。

于 2012-07-27T18:16:45.370 に答える