在更新網站上更改數據庫表

Question

這似乎是一個不斷出現在每個Web應用程序中的問題;您正在改進後端代碼，並需要更改數據庫中的表以便這樣做。在開發系統上手動執行沒有問題，但是當您將更新後的代碼部署到生產服務器時，他們需要自動更改數據庫表。

我見過各種各樣的方式來處理這些情況，都帶着他們的好處和自己的問題。粗略地說，我有以下兩種可能性：

1. 專用更新腳本。需要手動啓動更新。需要以預定義順序完成所有表格變更（嚴格的版本規劃，不容易快速修復數據庫）。通常需要維護一個單獨的更新過程和一些方法來記錄和管理版本號。好處是它不會影響運行代碼。

2. 在運行時檢查表屬性並在需要時更改它們。無需手動交互，並且可以按任何順序進行表格更改（因此可以快速修復數據庫，易於部署）。另一個好處是代碼通常更容易維護。顯而易見的問題是，它需要檢查表格屬性的數量遠遠超過需要。

有沒有其他一般的可能性或方式來處理應用程序更新時更改數據庫表？

Answer 1

我會分享我見過最好的工作。這只是擴展你的第一選擇。

在生產中更新模式時，我通常看到的步驟：

1. 取下來的前端應用。這可以防止在模式更新期間寫入任何數據。我們不希望寫入失敗，因爲關係混亂或者表突然與應用程序不同步。

2. 可能斷開數據庫，因此無法建立連接。有時候使用你甚至不知道的數據庫有代碼出現！

3. 按照您在第一個選項中所述運行腳本。這絕對需要仔細的計劃。您說得對，您需要預先定義的順序才能應用更改。另外我會經常注意到你需要兩組腳本，一組用於模式更新，一組用於數據更新。例如，如果要添加一個不可空的字段，則可以先添加一個可爲空的字段，然後運行腳本將其放入默認值。

4. 手頭上有回滾腳本。這一點至關重要，因爲您可能會進行所有您認爲需要的更改（因爲它在開發過程中運行良好），然後發現應用程序在您恢復聯機之前無法正常工作。有一個退出策略是很好的，所以你不會在這個可怕的地方「哦，廢話，我們打破了應用程序，我們已經脫機了幾個小時，我們做什麼？！」 （4）確實不好。

5. 協調應用程序更新與數據庫更新。通常你首先進行數據庫更新，然後推出新的代碼。

6. （可選）許多公司都會部分推出測試。我從來沒有這樣做過，但如果你有5個應用程序服務器和5個數據庫服務器，你可以先推出1個應用程序/ 1數據庫服務器，看看它是如何發展的。那麼如果它是好的，你繼續其餘的生產機器。

這絕對需要時間來找出最適合你的東西。根據我的經驗做大量的生產數據庫更新，沒有銀彈。最重要的是花時間和跟蹤變化的紀律（像你提到的版本）。