我目前正在開發一個web項目，在這個項目中我們都連接到一個開發數據庫。請提出一個更好的方式來組織開發數據庫
和其他集中式系統一樣，這個數據庫最終成爲單點故障。
如果其中一個開發人員不小心將一些髒數據轉儲到數據庫中，則所有其他開發人員都會受此影響。
因此，我認爲也許我們應該做一些事情，比如說，我們每個人都製作了原始數據庫的副本，並設置了我們的Web應用程序以連接到本地數據庫。
就我而言，團隊的核心成員是五個開發人員，一個測試人員（主要是黑盒測試）。開發過程如下所示：每個開發人員負責一個子功能並在他自己的分支上工作，然後我們將他的分支合併到測試人員測試應用程序的主幹上。
請給我一些建議。
讓每個人都從他們自己的數據庫副本中發展出來的問題是，他們不會接受其他開發人員的更改。
例如，如果有人向數據庫表中添加一列，其他開發人員將不會意識到這一點。其他人也可能無意中添加同一列。
而且，如果有人以需要更改應用程序代碼的方式更改存儲過程（例如，添加輸入參數），其他開發人員將不會知道這一點。如果他們從源代碼控制中獲得更新的代碼，它將無法在本地數據庫副本上工作。
我同意有一個日益混亂的開發數據庫是一個問題。但我不確定從數據庫的多個副本開發是否會減少開發問題的數量。
我認識到的一種替代方法可能不適用於您，它會定期將生產數據庫複製到開發中。通常，這隻能在新版本發佈後進行，這會使生產數據庫模式需要進行任何更改。但是你必須有一個生產數據庫來做到這一點。
就我個人而言，我發現同步開發人員更改更容易 - 您需要討論它們以免發生衝突 - 以及代碼更改，而不是嘗試使多個人員針對單個實例處理非同步代碼。以更大的粒度級別強制代碼/數據庫同步似乎允許每個人的移動速度比如果他們必須始終不斷更新其本地代碼副本以匹配單個數據庫。請注意，我正在討論整合雙週，每次迭代（最壞情況）而不是每天。我不會讓這些變化漂移得太遠。 – tvanfosson 2010-01-06 13:21:09
我同意你有一個本地數據庫副本的缺點。也許這就是隻能通過專注於問題本身而不是尋找最佳實踐才能解決的問題。 – satoru 2010-01-06 13:29:04
Red Gate（我工作的人）將用一種名爲SQL Source Control的產品解決這個問題（http://www.red-gate.com/Products/SQL_Source_Control/index.htm）。這將不會出現幾個月，但同時您可以將開發人員數據庫與SQL Compare進行同步。 – 2010-01-06 22:05:38
在我的項目上，開發數據庫總是在開發者本地機器上。我們使用SQL Server Developer Edition或SQL Server Express。我們保留一個用於在源代碼庫中創建簽入數據庫的SQL腳本。任何需要重新創建本地數據庫的人都可以使用它。一個團隊成員負責維護SQL腳本，並且首先將任何數據庫更改發送給他（如通常的SQL腳本）。他從SCM獲取最新版本的腳本，更新他的本地副本，並生成一個更新後的創建腳本，用於替換SCM中的腳本。同時伴隨代碼更改被檢入到SCM中，以便代碼和數據庫同步。其他人都同步到這個版本。
這使人們可以自由地並行工作並根據需要進行模式更改，包括可能會丟失的實驗更改。我們還使用本地數據庫作爲虛擬數據的源代碼來進行本地應用程序的測試 - 而不是單元測試，我們通常將數據庫模擬爲此，但是集成和UI測試。保持本地數據庫的獨立性允許每個開發者根據需要爲其測試進行設置，而無需與其他人協調。
我還應該提到，我們使用Red Gate's SQL Compare只在協調員的本地數據庫處於正式簽入版本時傳播更改。這是刪除和重新創建數據庫的替代方法，可以更好地保留現有數據。根據DB的變化，這可能是一個微不足道的或有點複雜的操作。我們一直使用它來更新質量保證/測試和生產數據庫，除非這些更改如此微不足道，以至於可以通過手工完成（沒有錯誤）。
我應該認定這是說這一直是一個相對較小的團隊。我認爲它會擴大或適應更大的團隊（團隊？），但我沒有任何直接的經驗。 – tvanfosson 2010-01-06 13:23:29
對我的公司來說工作得很好的解決方案是爲每個開發人員在虛擬機中運行數據庫。
我們爲每個支持的數據庫（oracle，db2，mssql，mysql）設置了一個虛擬機。現在每個開發人員都可以在本地簡單地複製和運行虛擬機，而無需安裝它。
我發現花時間建立一個系統，每個開發人員都有自己的數據庫，每次運行他們的單元測試時都會刷新，重建並填充測試數據，這非常有幫助。通過這種方式，你永遠無法彼此相處。當然，持續集成和測試服務器也應該有自己的數據庫。
只要DDL和測試數據在版本控制中，每個人都在針對同一個數據庫工作。另一個優點是，如果我正在開發一個需要更改數據庫的功能，則每個人都可以獲得代碼和DDL +測試數據。
在Java領域，DbUnit在我們的例子中與Hibernate Maven插件一起對此非常有幫助。當然，一個簡單的自制解決方案可能會很好。
我們使用與其他人在此描述的大致相同的基本過程，並進行了一些重大更改。每個開發人員通常都有自己的數據庫實例，並使用更改腳本進行管理。這裏是詳細信息：
由於模式更改腳本的版本號必須以文件名編碼，因此兩個開發人員都創建相同的版本腳本時可能會產生衝突，因此在點上會顯得有點草率。有時您可能會遇到處於不一致狀態的數據庫，並且自動過程將失敗。但總的來說，它對我們來說工作得非常好。
貴公司有多大？你有開發，測試和生產環境嗎？你有專門的測試團隊嗎？有很多變數，這是一個非常廣泛的問題。 – 2010-01-06 13:06:11