當我們第一次啓動源代碼控制時，開發人員只需編輯數據庫中的腳本，並在發佈之前編寫一個包含所有更改的大腳本。這很有效，直到其中一位開發人員意外刪除了存儲過程，所有工作都丟失了。SQL Server源代碼控制
之後，我們把所有的腳本來創建文本文件中的存儲過程和他們的源代碼控制。這裏的問題是，開發人員有時更新源代碼管理或數據庫中的存儲過程，並忘記更新另一個。
我的夢想就是一個開發中去，並檢查出一個存儲過程有一個系統。然後，更改後，數據庫會自動更新。
這只是一個夢嗎？源代碼管理SQL Server的最佳方式是什麼？
我們一直在使用Visual Studio Team System Database Edition最近，我不得不說，它一直非常好。所有的存儲過程都存儲爲文件，進出源控制的檢查，它有工具來生成腳本等存儲爲文本文件
而且，在過去，我們已經使用腳本，在檢查和脫離源代碼管理。規則是你必須檢出文件，然後編輯它，例如Management Studio，然後保存並重新檢入。在每個存儲過程腳本文件的頂部，它將刪除現有的存儲過程，然後使用CREATE語句創建一個新的（解決CREATE/ALTER問題）。然後，我們有了一個工具，可以按照正確的順序運行所有腳本，從頭構建一個空白數據庫，然後我們使用RedGate的SQL Compare產品生成一個腳本，以使我們現有的數據庫保持最新狀態。我承認這很乏味。大約在同一時間，我與其他約10名開發人員一起工作，他們實施了嚴格的數據庫變更管理程序。有許多應用程序都依賴於一組2或3個數據庫。每當數據庫模式必須改變時（我們只是在這裏討論表格，列和視圖），然後創建一個文檔來解釋變化，然後有一個矩陣列出了變化與我們認爲會影響的應用程序。然後，文件被分發，並且必須由每個應用程序的負責人進行審查，並且他們必須在任何可能受到影響的地方搜索他們的應用程序等等。這是一個漫長而艱難的過程，但它工作。但是，存儲過程只是作爲源代碼管理中的文本文件存儲。
在更久遠的過去，與更像一個數據庫作爲數據存儲，每一個應用程序啓動時的桌面應用程序規模較小的項目，我想：
每當我需要更改架構，我只是在啓動代碼的末尾添加更多代碼以根據需要修改架構，並注意遷移任何現有數據。這樣做的好處是您可以卸載並重新安裝新版本的軟件，並且會自動將現有數據庫升級到最新版本。安裝，升級和維護是一個夢想。儘管如此，這對於更多「企業」系統來說不起作用。
您可以通過採用ADO.Net實體或其他類似實體框架（如Entity Spaces）來減少其中一些問題。這些是對象關係映射層。它們爲數據庫中的每個實體（表）自動生成類，包括每列的屬性等。然後，它們允許您使用自定義邏輯擴展這些類。如果您可以擺脫存儲過程中的業務邏輯，並將它們放入實體類中，那麼它的好處是它們是強類型的。因此，如果您更改列的名稱或刪除列並重新生成實體類，那麼IDE或編譯器會自動標記代碼被破壞的所有位置。顯然，所有的實體代碼自然也在源代碼控制中，其餘的源代碼也是如此。
我見過源控制工作最適合在團隊環境中的SQL Server的方式是當DBA沒有定期使用數據庫的建立簽入代碼。它通常只需要一個丟失事物的實例，因爲在開發人員獲取圖片之前，它沒有簽入，因爲檢查他們的代碼意味着什麼。
希望這有助於
比爾
我曾在源代碼控制是發佈過程的一部分的環境中工作。
DBA被授予發行說明，要求DBA從源代碼控制獲取，然後從那裏釋放存儲過程更改或SQL腳本。如果您可以將DBA放在一邊，那麼這是避免放棄版本的好方法，因爲您應該能夠在UAT系統上預先測試SQL。
如果數據沒有發佈到源代碼管理中，那麼它不會被釋放。
集成分支用於釋放代碼。
我們一直使用SQL Server 2000附帶的scptxfr實用程序將數據庫腳本編寫到存儲在源代碼管理下的文件中。
我們在做檢查之前運行它，它會突出顯示發生的任何機會（無論預期與否）。它不會在2005或更高版本中出現，但如果您有任何舊版本的2000年版本，它仍然可以對付新版本。它可能對複雜的模式有問題，但它是一個很好的起點。當與源控制觸發器或持續集成結合使用時，它也可以成爲自動過程。
關鍵是要限制只有少數人的權利，並堅持認爲除了通過調用源代碼管理腳本之外，他們不會進行更改。在最新版本的SQl Server中，您還可以設置DDL日誌記錄以準確找出將該表更改爲不在源代碼管理中的版本的人員！
當我們第一次切換到在我們的數據庫上使用源代碼控制時，每個人都擁有prod權限（我們已經固定），所以我們有一個dba定期比較源代碼控制check in與實際prod數據庫，並擺脫任何未經授權的更改。它只花了一次的時間來說服開發人員他們必須使用源代碼管理。
紅門SQL源代碼控件將源代碼管理完全集成到SQL Server Management Studio中。這有效地將您的開發數據庫鏈接到您現有的源代碼管理系統（TFS和SVN），只需點擊一個按鈕即可提交更改並檢索其他開發人員的更改。
http://www.red-gate.com/products/SQL_Source_Control/
現在，我們已經加入VSS和SourceGear庫支持的EA版本。更多細節在這裏：http://www.red-gate.com/MessageBoard/viewtopic.php?t=12265
我最近寫了一個腳本來幫助我們解決這個問題 - 它不是完全的源代碼管理，它只是一個存儲過程，它將數據庫對象的歷史存儲在一張表中 - 你可以使用SQL代理將其安排爲按需要運行。
雖然它會在某個時間點拍攝快照，但它並不真正支持簽入，但是當存儲的proc在沒有備份的情況下被丟棄或更改時，它已經保存了幾次培根，以前的版本很容易恢復。
http://trycatchfinally.net/2011/06/roll-your-own-lightweight-sql-server-source-control/
獲得開發商要記得提交代碼是棘手的。
它的另一端更容易一些，因爲一旦更新在源代碼管理中，它們可以通過腳本自動生成一個新的數據庫/或者從源代碼管理中刪除並重新創建一個數據庫。
看看這個免費的product這將有助於建立一個SQL Server數據庫的基準。
該工具還將從源代碼控制中構建數據庫 - 因此從理論上說，您可以讓X開發人員在項目中工作，並且他們都可以將其他源代碼從源代碼運行到自己的數據庫中 - 反之亦然，他們的更新回到源代碼控制。
不幸的是， - 我想不出如何讓開發人員記得提交數據庫更改。也許他們可以運行一個工具（或批處理文件），它將執行本地數據庫拉到源代碼控制，然後養成通過批處理文件運行這個重複任務的習慣 - 每次他們來做一個拉/提交源控制？
這是一個大問題，我問了很多時間，但沒有很好的答案，唯一的答案似乎是通過操作程序來協調它。 – tekBlues 2009-07-01 14:26:35
由於這個原因，我們創建了http://tessik.com/sqlhistorian：依靠開發人員更新他們的版本控制以防止他們在數據庫中執行的操作是徒勞的。一旦T-SQL擊中服務器，我們的系統就會自動將更改記錄到源控件，而無需任何其他用戶交互。 – 2015-02-04 17:04:56
許多公司**不允許**開發人員直接將腳本應用到生產環境中，所以我認爲最好的方案是允許（DBA）從腳本更新**到數據庫**，而不是相反。但是，在現實世界中，有人可能沒有正確地遵循變更程序，所以**最好是允許雙向比較。試試這個免費工具：** [http://servantt.com]（http://servantt.com/?so） - 它允許你逆向工程你的對象，保存到腳本，比較數據庫和腳本，啓動WinMerge for比較，更新腳本或將更改應用到數據庫。 – drizin 2016-01-28 21:05:45