完全なスクリプト ベースまたはデータベース デルタ ツールとは対照的に、データとスキーマの移行の基礎としてダンプ ファイルを使用することの長所と短所は何ですか?
コンテキストは、アプリケーションが本番環境にあり、本番データベースが 1 つしかないということです。アプリケーションとデータベース スキーマは活発に開発されています。重要なユーザー データは運用データベースに存在し、新しいバージョンまたは修正プログラムの展開と共にロール フォワードする必要があります。
議論されているソリューションは次のとおりです。
ダンプファイル単位 -
- 参照点のダンプ ファイルから始めます。
- データベース変更スクリプトは、ソース管理にチェックインされます。
- 展開には、ダンプ ファイルの読み込みと、変更スクリプトの実行が必要です。
スキーマ + 移行
- スキーマ全体と特定の非ユーザー構成データは、DDL および DML として SCM に格納されます。
- 最新リリースのスキーマに対する移行スクリプトは、SCM に保存されます。
- デプロイメントには、スキーマのロードとデータの移行が伴います。3.
私の直感では、バイナリ形式をベースとして使用することは悪いことですが、それが必要であると主張する他の人 (実際にそうである場合) を説得できるようにする必要があります。
答えやすくするために、この質問を再定式化しました。
以下は元の質問です。
私はデータベース駆動のエンタープライズ アプリケーションのチームと協力しており、プロセスの改善を目指しています。現在、すべての層でデータベースを更新するために多くの手動プロセスがあります。目標は、データベースを一貫して自動化された方法で更新するための自動化されたプロセスを持つことです (アトミックコミットのアイデアに沿って、継続的な配信に近づく)。これにより、多くの利点がもたらされます。
スキーマ (およびアプリケーションの構成に必要な特定のデータ) は、ソース管理で表す必要があると思います。さらに、現在の運用データベースからユーザー データを変換およびロードするために必要なスクリプトも必要です。ソース管理にダンプ ファイル (.dmp) を配置することはお勧めできないと読みましたが、直感的に強く同意します。しかし、私はプロジェクトの全員から同意を得ているわけではありません。反対意見は、実際には、ダンプ ファイルから始めないことは不可能であるか、少なくとも非常に困難であるというものです。私はデータベースの知識の限界に直面しており、意味のある議論をすることができません... 私は開発者であり、データベースの専門家ではありません。別の方法として、ダンプを最新のスキーマに変更する変更スクリプトを保持することをお勧めします。
誰かが各アプローチの長所と短所をもう少しよく理解するのを手伝ってくれますか? ダンプベースのアプローチは必要か、良いアイデアか、そうでないか、そしてその理由は?
関連する可能性のある少しの背景: アプリケーションは運用中なので、新しいバージョンごとに展開プロセスの一部としてデータをインポートする必要があります。統合と UAT 層に関する明らかな理由から、これは実際のデータである必要があります。ただし、このアプリは顧客によって「出荷」およびインストールされるわけではありません。特定の時点で実稼働のインスタンスが 1 つしかなく、内部で維持されます。私のプロジェクトに固有の詳細があることを認識しているため、答えは一般的なケースに対処する必要があります。