動態修補數據庫

請原諒我長期以來的問題。我有一個設計的想法，我可以使用一些評論。這樣做是個好主意嗎？那我應該注意的是什麼坑？還有其他類似的實現更好嗎？動態修補數據庫

我的情況是這樣的：
我在窗口的工作重寫窗體應用程序連接到SQL 2008（以前它是SQL 2005服務器）。該應用程序是一個工程公司的「專家系統」，我們存儲關於結構的結構化數據。我們可以控制所有客戶端軟件的安裝，我們沒有外部客戶或用戶，它們都是公司內部的，他們都是可信的，不會對軟件或數據庫產生任何惡意行爲。

當前的設計沒有太多的表格（大約10 - 20），但其中一些有幾百萬條記錄屬於幾百個結構。迄今爲止系統的性能一直不錯，但隨着我們推動設計的極限，它開始下降。

作爲重寫的一部分，我正在考慮將數據庫拆分成一個主數據庫和幾個「子」數據庫，其中每個數據庫描述一個構造。每個兒童數據庫應該具有相同的設計。這應該消除我們今天看到的性能問題，因爲存儲在每個數據庫中的數據將少於總數據量的百分之一。

我擔心的是，我們現在不會維護一個數據庫，而是要獲得數百個必須保持最新的數據庫。隨着公司需求的變化（你知道它是如何變化的），系統一直在不斷髮展，儘管我們試圖期望減少變化的數量，但變化將會發生。所以我們需要一個系統來跟蹤系統所做的所有數據庫更改，以便將它們應用於子數據庫。更新客戶端應用程序不會是一個問題，我們對這方面有很好的控制。

我想到一個更改跟蹤系統，我們在主數據庫的一個表中存儲所有更改的數據庫腳本。然後，我們可以給每個更改一個版本號，我們可以在每個子數據庫中存儲一個當前版本號。當客戶端程序連接到子數據庫時，我們可以根據主數據庫的當前版本號檢查數據庫的版本號，如果有版本號大於子數據庫版本號的修補程序，我們運行這些更新並更新將子數據庫更新到最新版本。

正如我所見，這應該很好。系統的任何更改都將首先經過測試和驗證，然後作爲新版本的數據庫提交。然後，該更改將在用戶第一次打開數據庫時應用到數據庫。我想我們會在應用更改時以獨佔模式打開數據庫，但只要更改不太頻繁，這應該不成問題。

那麼你怎麼看？這會工作嗎？你們有沒有做過類似的事情？我們是否應該廢棄解決方案並轉而使用單片系統？

來源

2008-10-31 Rune Grimstad

我在這裏有類似的情況，雖然我使用MySQL。每個數據庫都有一個版本表，其中包含版本（只是一個整數）以及此版本中已更改內容的簡短評論。我使用腳本來更新數據庫。每個數據庫更改都可以在一個功能中進行，或者有時可以通過多個功能進行更改。函數包含函數名稱中的版本號。該腳本查找數據庫中的最高版本號，並僅應用具有更高版本號的功能。

這使得它更容易更新數據庫（只需添加新的更改功能），並允許我在必要時快速升級恢復的數據庫（只需再次運行腳本）即可。

即使在測試更改之前允許進行防禦性更改。如果您在一個表中的一些沉重的變化，你想發揮它的安全：

def change103(...): 
    "Create new table." 
def change104(...): 
    """Transfer data from old table to new table and make 
     complicated changes in the process. 
    """ 
def change105(...): 
    "Drop old table" 
def change106(...): 
    "Rename new table to old table"

如果change104（）是出亂子（並拋出一個異常），你可以簡單地刪除已經從新的轉換數據表，修復您的更改功能並再次運行腳本。

但我不認爲在客戶端連接時動態更改數據庫是個好主意。有時更改可能需要一些時間。訪問數據庫的軟件應與數據庫的模式匹配。你有辦法讓它們保持同步。也許你可以分發一個新的軟件版本，然後你想在客戶端真的開始使用這個新軟件時升級數據庫。但我沒有嘗試過。

來源

2008-10-31 10:14:01