2011-02-10 58 views
3

我最近開始了一項新工作,他們通過存儲過程完成了大部分工作。我們目前有一個包含與數據庫更改腳本時間戳的文件夾(我們確實有在這3個文件夾 - 一個用於表修改腳本,一個用於視圖和功能,以及一個用於存儲過程)源控制下的「部署」文件夾,以及一個「下一個」文件夾包含我們目前正在進行的新更改(在部署時它將被重命名)。我們設置了三個數據庫:工作站上的本地副本,僅供個人開發人員,開發數據庫和生產中的實時數據庫訪問。在.NET中處理數據庫更改/腳本?

這意味着我們創建並提交.SQL文件,然後必須幾乎每天都手動運行它們(因爲新增加到源代碼控制中,所以幾乎每次我們進行更新時都需要檢查這些文件夾中發生了什麼變化,並根據我們的本地數據庫副本運行它們),更不用說在部署時必須在dev和prod服務器上執行相同的操作;我們也有在每臺服務器上不同的名稱數據庫,以避免意外在錯誤的環境中運行的變化腳本(這令我奇怪的是通常你有DB 實例命名不同,但在所有的服務器命名爲等同實際的數據庫),所以我們不能在腳本中包含USE語句。這個過程似乎非常低效。

是否有處理這種事情,我會建議使用,而不是我們開始推薦的最佳實踐方法是什麼?

+2

相似的問題在這裏:http://stackoverflow.com/questions/2401229/database-structure-and-source-control-best-practice – Paddy 2011-02-10 15:27:41

回答

1

我一直在使用Visual Studio數據庫項目來處理該問題大約一年了。它有一點點的學習曲線,並不完全沒有打嗝,但它肯定比嘗試手動管理這個過程要好。

正如其他人所指出的,你應該計劃在一個相當大劑量的保理「它處理我們的情況,」與一般的最佳實踐一起。在我的例子中,我有多個開發分支,這些分支進入集成環境,還有一些相當嚴格的DBA類型人員。這兩種方式都造成了一些複雜的問題,我希望你也會遇到類似的情況。

0

SQL Source Control是我們會在紅門建議爲你分擔開發商之間變化的工具。這集成到SSMS中,並與您現有的源控制系統一起使用。 SQL Compare最適用於部署,而不是頻繁的用例,例如在開發環境中共享更改。如果由於某種原因SQL源代碼控制不適合您,我們很樂意聽取您的意見。