應用程序的多個版本使用的數據庫的最佳實踐
我正在開發一種新產品，該產品將在我們的客戶內部執行。此應用程序的配置和使用將儲存在數據庫中。其中一項要求是，新版本的應用程序可以與舊版本並排安裝。通過這種方式，客戶可以驗證我們軟體的新版本，並且可以將他的業務流程從舊版本稍微遷移到新版本。可能這將在每個過程中完成，因為它將涉及大量測試和驗證。
在遷移到新版本結束時，兩個版本的應用程序的所有配置更改和執行/使用數據都應該存在於數據庫中。這意味著應用程序的兩個版本都必須使用相同的數據庫。
那麼我們應該如何處理應用程序未來版本中的數據庫更改？我們如何確保舊版本的應用程序仍然可以使用升級後的數據庫？我正在考慮以下方法，但也許有更好的方法來解決這個問題：
- 在應用程序和數據庫之間創建一個 API 層。如果安裝了較新的版本，它將更新數據庫和 API 層。API 層將以向後兼容的方式提供對數據庫的訪問，並將被所有已安裝的應用程序版本使用。
還有其他想法或建議嗎？
FWIW：我們還沒有決定數據庫，可能是 MySQL、PostgreSQL 或 MS SQL。
“應用程序的多個版本使用的數據庫的最佳實踐”是根本沒有這樣的東西。
您要做的是為您的客戶建構一個新環境（稱為預生產、使用者驗收測試或其他），以進行驗證和培訓。您使用遷移過程（稍後將用於遷移生產實例）使用目前生產中的數據填充它。
一旦客戶簽署發布，您就可以部署新程式碼並在生產中遷移數據庫模式和數據，以任何合適的順序進行。您可以在一個全新的生產環境（然後淘汰目前的生產）或就地（如果停機時間是可以忍受的）進行。
這就是甲骨文和 SAP 等大公司的做法，你也應該這樣做。
這與在網際網路上執行的任何其他 24/7 服務沒有任何不同。通常此類服務的部署沒有維護停機時間，因此它們必須允許與舊版本一起部署新版本。如果是短時間（僅在部署過程中），則稱為藍綠部署；兩個版本的長期共存將是 Canary Releases。
在這兩種類型的版本中，我們都希望盡量減少必須支持舊版本的時間。它存在的時間越長，我們必須維護的臨時解決方案就越多，一旦它們開始重疊，它就會變成一場噩夢。但總體原則不會改變：您需要保持向後兼容並支持向前兼容。
向後兼容性
為此，您的新版本 (v2) 與之前的版本 (v1) 相比只能引入附加更改。含義 - 沒有重命名和刪除上一版本使用的列。如果需要重命名，則必須在 v2 中添加新列，並在 v3 中刪除舊列。
雖然 v1 存在，但您必須維護舊數據。這意味著即使您不再需要它們，您也必須寫入舊列。
前向兼容性
這個比較棘手。如果你在 v2 中創建一個新的列或表，如果你的 v1 不知道它會如何填充它？解決方案可能是：
- 使用觸發器。因此，如果我們只插入 OLD_COLUMN，那麼 NEW_COLUMN 會自動填充。
- 但是邏輯可能會變得更加複雜，並且使用觸發器執行此操作可能變得不切實際。在這種情況下，您可能必須將您的版本拆分為多個版本：v2.1 添加一個新列但不使用它，v2.2 開始填充它但不使用它，最後 v2.3 遷移舊的數據並開始充分使用它。
如果您有頻繁的發布（持續傳遞），那麼這種複雜性是可以管理的，發布週期越長，所需的能量就越多。
您可能可以通過查找“Canary Releases”以及“數據庫向後和向前兼容性”來找到更多資訊。