在工作中，我們有4個人在幾個不同的項目上一起工作。對於每個項目，我們都有一個本地副本，然後進行開發，暫存和實時部署，以及我們擁有的任何分支（我們使用Subversion）。我們的數據庫是MySQL。如何在具有分支機構的中型項目上管理數據庫修訂版本？
所以我的問題是，什麼是管理對每個部署（以及開發人員本地副本）對數據庫進行哪些修訂的好方法。現在，每次更改都會進入一個文本文件，該文件在名稱中加上時間戳，並放入項目下的文件夾中。老實說，這不是很好。我需要一個解決方案來幫助跟蹤哪些地方應用了什麼。
如果您的數據庫很好地映射到一組數據訪問對象，請考慮使用「遷移」。這個想法是將你的數據模型作爲應用程序代碼存儲起來，並在每個數據庫版本中前後移動。我相信Rails did it first。
Java有at least one project。
而且這裏有一個.NET migration library。
要更改版本，你運行一個簡單的腳本，通過所有的向上或向下版本的步驟讓你你想要的版本。它的美妙之處在於，您可以將您的遷移與您的應用程序代碼一起檢入同一個源代碼庫 - 全部集中在一個地方。
也許別人可以建議其他遷移庫。
乾杯。
編輯：參見https://stackoverflow.com/questions/313/net-migrations-engine和.NET database migration tool roundup（從上面交）。
http://odetocode.com/Blogs/scott/archive/2008/01/30/11702.aspx
上述博客給我們帶來了我們現在的數據庫版本控制系統。簡而言之，沒有更新腳本就不會更改數據庫，並且所有更新腳本都位於我們的源代碼管理存儲庫中。
我們只管理模式更改，但您也可以/願意考慮在版本控制中保留數據的轉儲;使用mysqldump創建這樣的文件是非常簡單的練習。
我們的解決方案與博客中呈現的解決方案有一個不同之處：它不是自動化的。我們必須手動應用數據庫更新等。雖然這可能會稍微耗時，但它推遲了全自動化系統所需的部分工作量。然而，我們做了一個自動化的事情，就是軟件中的數據庫版本跟蹤：這非常簡單，它確保我們的軟件知道它正在運行的數據庫，並且只有在知道它正在使用的模式時纔會運行。
我們解決方案中最難的部分是如何將我們分支的更新合併到我們的主幹中。我們花了一些時間來開發一個工作流，以解決兩個開發人員嘗試將分支與數據庫更新同時合併以及如何處理它的可能性。我們最終決定在版本控制中鎖定一個文件（我們討論的文件實際上是一個將軟件版本映射到db版本的表格，這有助於我們的手動管理策略），就像您對線程的關鍵部分以及開發人員鎖繼續關於他們的幹線更新。完成後，其他開發人員將能夠鎖定，他們有責任對其腳本進行必要的更改，以確保避免預期的版本衝突和其他不良Juju。
我們將所有的數據庫腳本（data和schema/ddl）保存在版本控制中。我們也保留一箇中央目錄的變化。當開發人員更改模式/ DDL文件或添加以某種方式更改數據的腳本時，這些文件將與SVN提交編號一起添加到目錄中。
我們已經組建了一個內部小公共事業公司，它通過抓取目錄中每個修訂版的內容並應用它們來讀取目錄更改，並根據目錄內容構建一個較大的更新腳本。這個概念非常類似於DBDeploy工具，我相信它最初來自Thoughtworks，所以您可能可以使用它。它至少會爲您提供一個開始的好地方，從這個角度您可以定製更適合您需求的解決方案。
祝你好運！
我已閱讀本，和誠實，我不喜歡這個主意。我認爲需要構建一個完整的系統才能真正爲多個部署提供支持。 – Greg 2008-10-01 02:57:39
在您所描述的內容中增加了一些內容：確實需要構建一些基礎結構工具以獲得該解決方案，但並非所有工具都是必需的（我們選擇不允許該軟件「自我更新」），並且這是一個強大的解決方案，初期的努力很快就會收回成效。 – antik 2008-10-01 03:10:46