我們有一個數據庫，其中存儲了來自外部系統的標識符。現在標識符已更改（系統更改了方案），並且數據庫需要更新。它可以完成 - 我有一個映射，所以我可以生成足夠的SQL來使它工作，最後這將需要這樣做。Flyway Java遷移是這個用例的合適工具嗎？
問題是 - 這是用於Flyway Java遷移的用例嗎？我傾向於認爲情況並非如此，但我無法真正說出原因，這是一種直覺。但是，外部系統的模式沒有版本化，至少不是我們的，所以我覺得它根本不適合Flyway遷移;我認爲它應該在Flyway之外執行一次。
任何有更多經驗的人都可以幫忙，解釋爲什麼或爲什麼不？
它主要是基於意見的，但在我看來，因爲它與使用蒸汽錘來破解堅果一樣。對於定期遷移而言，Flyway是一個非常有用的工具，對於這種情況，還有很多數據庫，您必須定期重新創建或更新，而不是一次性使用。
在您的項目中包含一些相對較大的框架，花費一些時間使其工作並僅使用一次的原因是什麼？此外，Flyway需要在數據庫中存在一些額外的表格，以存儲關於當前版本和應用遷移的內部信息。不要以爲，那是你真正想要的。
就我而言，我認爲，如果你做這個任務了一次，並且可以不用遷飛，然後就去做這樣。
我想一個問題，我們應該問自己，當我們確定是否寫一個劇本遷飛爲我們的數據遷移是「從頭開始創建該數據庫時這個必要嗎？」
遷飛使用版本控制系統，使你的情況，這將是有意義的從舊版本翻轉值到新版本站在了一個新的環境時？怎麼樣多重修改？如果您正在創建新的環境，是否有意義地存儲舊值並將它們順序應用？
如果您回答「否」，那麼flyway可能不是您要走的路。 Flyway更好地用於架構更改，其中數據庫的結構發生更改並且數據轉換爲新結構。如果您只是更改配置值，我認爲flyway可能不是您最好的選擇，因爲沒有必要存儲對這些配置值的所有更改。
我們已經在使用Flyway，並有少量的遷移，所以這不是我們是否應該使用它的問題。問題是這個用例是否是Flyway應該使用的東西。在此遷移中，不會更改架構，只是在外部系統中的架構發生更改後要更改的數據。 – wujek
我現在看到並假設你也必須在你的問題中指定這個。但是，無論如何，我仍然認爲如果這是一次遷移，而遷移必須應用於唯一的一個數據庫實例並且只有一次遷移，那麼它不是Flyway的用例。此外，它不影響模式。 – Stanislav