私が抱えている次の問題に対する標準的なアプローチを見つけようとしています。
コンテナー (具体的には Tomcat) にデプロイされた Web アプリケーションがあり、その機能のためにデータベースを使用します (私の場合、ファイル モードの SQL データベースであるため、バックエンド SQL サーバーはありません)。
私が興味を持っているのは、データベース スキーマの変更 (新しいテーブル/新しい列、列の削除など) に応じて、Web アプリケーションの新しいバージョンでデータベースのさまざまな変更を処理する最良の方法は何かということです。
つまり、誰かが私の Web アプリケーションの新しいバージョンにアップグレードした場合に、古いデータベースの古いデータを最良の (自動?
これはまれなケースではないと思うので、ここで従うことができるいくつかのベストプラクティスがあると思います.
誰でもこれについて私を助けることができますか?
最近、 Flywayを発見しました。これは非常にうまく機能し、データベース スキーマの変更 (プレーンな SQL スクリプト) のバージョン管理を取り入れています。
明らかに、このトピックははるかに広いです。たとえば、アプリケーションの古いバージョンと新しいバージョンの両方が更新されたスキーマで問題なく動作する必要がある場合は、特に注意する必要があります。また、ロールバック戦略を検討する必要があります (アップグレードがうまくいかなかった場合、またはアプリケーションをダウングレードしたい場合) - 追加されたオブジェクト (テーブル、列) を削除するのと同じくらい簡単な場合もありますが、スクリプトが何かを削除した場合、ロールバックはそれらを復元する必要があります。
まず第一に、データベースへの変更、特に既存の列への変更をできるだけ少なくしたいと思うでしょう。
第 2 に、列の名前を変更したり、制約を変更したりする必要がある場合 (一致しないデータが存在する可能性があるため、制限を厳しくしないように注意してください)、ALTER TABLEステートメントを使用します。このようにして、列を削除しない限り、列のデータは保持されます。:)
さらに、これらの制約に違反しないように更新する必要があるテーブルにデータセットが既に存在する可能性があるため、制約 (null でないなど) を持つ新しい列に既定値を指定します。(または、列を追加し、いくつかのコードを実行して列を埋めてから、制約を追加します。)
第 3 に、アプリケーションには複数のユーザーがいるようで、バージョンが異なる可能性があるため、更新を提供する最も簡単な方法は、次に高いバージョンへの順次更新を提供することです。したがって、誰かがバージョン 2 から 5 に更新したい場合、最初に 2->3 更新を行い、次に 3->4、最後に 4->5 を行います。
これは実行に時間がかかる場合がありますが、ボットが可能なすべての組み合わせ (例: 2->4、2->5、3->5 など) を考慮する必要があるため、複雑さは軽減されます。