私のプロジェクトには、頻繁に変更されるビューやストアド プロシージャなどのオブジェクトが多数含まれています。実際には数行しか変更していないにもかかわらず、変更されたオブジェクトの完全なソース コードを含む新しい SQL スクリプトを更新ごとに作成する必要があります。これは大規模なコードの重複につながり、これらの変更をレビューすることも困難であることがわかりました。
ビューやプロシージャなどのオブジェクトごとに実際のバージョンの SQL スクリプトを 1 つだけ用意し、データベースを再デプロイするたびにこれらのオブジェクトを再作成したいと考えています。その結果、ビューまたはプロシージャを変更する必要があるたびに新しい更新を作成する代わりに、既存のソース ファイルを (Java または C プログラミングのように) 変更することができます。
Flyway でデータベースを移行するたびにスクリプトを実行する可能性はありますか?
なぜこれほど多くの反対票が集まったのかはわかりませんが、それは完全に理解できる有効な質問です。おそらく、それはこの未解決の質問によく似ているためです: Flyway を使用したストアド プロシージャの移行
私たちは実際にこの問題に反対し始めています。Flyway を開発とテストに使用してきました (そして気に入っています)。しかし、procs/triggers/views (p/t/v's) を使用しなければならなくなり、以前の方法と flyway を使用する必要がある方法との間の根本的な断絶が始まりました。緊張する。
以前は、特定のデータベース オブジェクト (プロシージャとしましょう) に対して、1 つのソース ファイルが存在していました。また、proc を「n」回変更する必要がある場合、VCS には同じファイルの「n」バージョンが存在します。差分ツールはうまく機能し、IDE はすべてこれを理解し、マージは別々のブランチで作業している 2 人の開発者が proc に変更を加えると検出します。
しかし、flyway を使用すると、'n' 個の変更を含む 1 つの proc が 'n' 個のファイルに分散されます。「'n' バージョンの 1 つのファイルに 1 つのオブジェクト」ではなく、「'n' 個のファイルに 1 つのオブジェクトがあり、それぞれに 1 つの変更があります」。proc の変更履歴を知りたい場合は、IDE で「proc_name」のインスタンスをテキスト検索する必要があります。VCS はそれについて何も知りません。開発者は、それぞれが展開されたときに成功する独自のブランチで移行を行うことができますが、proc には更新がありません。
私はフライウェイについて文句を言うつもりはありません。フライウェイが単純な領域ではないことは十分承知しています。私はそれが（フライウェイによって）解決できないとほとんど言います。
私たちはこの問題をどのように処理するかを計画しています。他の人がどのように処理したかを知りたいです.