SQL Server數據庫變更工作流程的最佳實踐

Question

背景

我的小組有4個SQL Server數據庫：

• 生產
• UAT
• 測試
• 開發

我在開發環境中工作。當需要推廣我一直在研究的對象（表格，視圖，函數，存儲過程）時，我向我的經理提出了一個請求，他向促進測試。經過測試，她向向UAT推銷的管理員提交請求。在成功進行用戶測試後，同一管理員將推向生產。

的問題

整個過程是尷尬的幾個原因。

1. 每個人都必須手動跟蹤他們的更改。如果我更新，添加，刪除任何需要跟蹤的對象，以便我的升級請求包含我所做的一切。從理論上講，如果我錯過了測試或UAT應該抓住它的地方，但這不是確定的，反正它浪費了測試者的時間。
2. 我做的很多修改都是迭代的，並在GUI中完成，這意味着沒有記錄我所做的更改，只有最終結果（至少據我所知）。
3. 我們正處於構建數據集市的初期階段，因此大部分更改（至少按計數方式）都是次要的：更改列的數據類型，將表的名稱更改爲我們結晶就是他們將被用於，調整功能和存儲的特效等

問題

人們一直在做這方面的幾十年的工作，所以我想有得成爲管理流程的更好方式。我會喜歡的是，如果我可以在兩個數據庫之間運行差異來查看結構如何不同，請使用該差異來生成更改腳本，並將該更改腳本用作我的促銷請求。這可能嗎？如果沒有，是否有其他方法來組織這個過程？

爲了記錄，我們是100％的微軟商店，剛剛將所有內容更新到SQL Server 2008，因此該軟件包中提供的任何工具都是公平的遊戲。

---

我應該說明我不一定在尋找diff工具。如果這是同步我們的環境的最佳方式，那麼很好，但如果有更好的方式，我正在尋找。

一個我想做得很好的例子是Ruby on Rails中的遷移。死簡單的語法，所有更改都會自動記錄下來，默認情況下，確定遷移需要運行的幾乎非常簡單。如果對於SQL Server有類似的東西，我很樂意。

我的理想解決方案是1）容易和2）很難搞砸。 Rails遷移都是;到目前爲止，我在SQL Server上所做的一切都不是。

Answer 1

Version Control and your Database

萬物罪惡的根源正在於用戶界面的變化。 SSMS是一個DBA工具，而不是開發人員。開發人員必須使用腳本對數據庫模型/架構進行任何類型的更改。對元數據進行版本控制並從每個版本N到版本N + 1的升級腳本僅有經證明可以可靠工作。這是SQL Server本身用來跟蹤元數據更改（資源數據庫更改）的解決方案。

來自VS數據庫項目的SQL比較或vsdbcmd和.dbschema文件等比較工具對於未能採用適當版本化方法的商店來說只是最後的選擇。他們在簡單的情況下工作，但我發現他們都在嚴重部署中失敗。一個只是沒有對數據庫信任的工具做了更改+ 5TB表，如果這些工具試圖複製的資料...

Answer 2

RedGate銷售SQL Compare，這是一個很好的工具來生成更改腳本。

Visual Studio也有支持數據庫比較的版本。這以前叫做Database Edition。

我在哪裏工作，很久以前我們廢除了Dev/Test/UAT/Prod分離，轉而使用very quick release cycle。如果我們把生產中的東西弄壞了，我們會很快修復它。我們的客戶當然更快樂，但是冒險避免企業事業，這可能是一種艱難的銷售。

Answer 3

有幾種工具可供您使用。一個來自Red-Gate，名爲SQL Compare。真棒，強烈推薦。 SQL Compare可以讓你在兩個數據庫之間的模式中做一個diff，甚至爲你建立sql更改腳本。

請注意，他們現在也一直在研究SQL Server源代碼管理產品。

另一個（如果你是一個視覺工作室商店）是作爲Visual Studio一部分的模式和數據比較功能（不知道哪些版本）。

Answer 4

在我們的團隊，我們處理數據庫的變化是這樣的：

• 我們（重新）生成一個腳本其中創建完整的數據庫，並與其他更改檢查到版本控制在一起。我們有4個文件：表格，用戶定義的函數和視圖，存儲過程和權限。這是完全自動的 - 只需要雙擊即可生成腳本。
• 如果開發人員必須對數據庫進行更改，她會在她的本地db上進行更改。
• 對於每一項更改，我們都會創建更新腳本。這些很容易創建：開發人員重新生成本地數據庫的數據庫腳本。由於版本控制，所有更改現在都很容易識別。大多數更改（新表，新視圖等）可以簡單地複製到更新腳本中，其他更改（例如添加列）需要手動創建。
• 更新腳本在我們的通用開發數據庫上被測試，或者通過回滾本地數據庫到最後一次備份 - 這是在開始更改數據庫之前創建的。如果它通過，是時候提交更改。
• 更新腳本遵循命名約定，因此每個人都知道以何種順序執行它們。

這對我們很好，但如果幾個開發人員大量修改相同的表和視圖，仍然需要一些協調。但這並不經常發生。

重要的要點是：

• 數據庫結構只是通過腳本修改，除了本地開發商的分貝。這個很重要。
• SQL腳本由源代碼控制版本 - 數據庫可以創建，因爲它是在過去
• 數據庫中的任何點備份創建定期 - 至少在更改數據庫之前
• 對數據庫的更改可以快速完成 - 因爲這些更改的腳本相對容易創建。

但是，如果您的項目有很多持久的開發分支機構，則可能無法正常工作。

這是迄今爲止不是一個完美的解決方案，並採取一些特殊的預防措施。例如，如果存在可能因數據庫中存在的數據而失敗的更新，則應在生產數據庫的副本上測試更新。

與rails遷移相反，我們不創建腳本來反轉更新的更改。但是，至少在數據方面，這並不總是可能的（即使重新創建列，丟失列的內容也會丟失）。

Answer 5

同意SQL比較是一個了不起的工具。

但是，我們不會對數據庫結構或對象進行任何更改，這些數據庫結構或對象不像其他代碼那樣腳本化並保存在源代碼管理中。然後，您確切知道您正在推廣的版本屬於哪個版本，因爲您擁有該特定版本的腳本。

無論如何，通過GUI進行結構更改是一個壞主意。如果你有大量的數據，它至少比在SQL Server中使用alter table慢得多。你只想使用測試腳本來更改prod。

Answer 6

另一種「差別」工具：

http://www.xsqlsoftware.com/Product/Sql_Data_Compare.aspx

Answer 7

我同意marapet提出的意見，每個變更都必須編寫腳本。
但是，您可能遇到的問題是創建，測試和跟蹤這些腳本。
查看DBSourceTools中使用的修補引擎。
http://dbsourcetools.codeplex.com

它專門設計用於幫助開發人員在源代碼控制下獲取SQL服務器數據庫。

這個工具將允許你在特定點爲你的數據庫建立基線，並創建一個命名版本（v1）。
然後，創建一個部署目標 - 並將指定的版本增加到v2。
將修補程序腳本添加到Patches目錄中，以更改模式或數據。
最後，檢查數據庫和所有補丁到源代碼控制中，與開發人員分發。

這給你一個可重複的過程來測試從v1到v2應用的所有補丁。
DBSourceTools還具有幫助您創建這些腳本的功能，即模式比較或腳本數據工具。

完成後，只需將patches目錄中的所有文件發送到DBA以從v1升級到v2即可。

玩得開心。在一個版本表

記住這是腳本文件名

Answer 8

1. 保持數據庫版本的成功應用
2. 記住，已應用於每個SQL腳本的MD5校驗和。計算md5總和時應忽略空格。必須有效。
3. 保持對誰適用的腳本保存在施加腳本有關信息資訊
4. 數據庫應在應用程序進行驗證的啓動
5. 新的SQL腳本應該自動
6. 應用如果腳本的MD5和那已經應用被改變了，應該拋出錯誤（在生產模式下）
7. 當腳本被釋放時，它不能被改變。它必須是 在生產環境中不可變的。
8. 腳本應該寫的方式，因此它可以被應用到不同類型的數據庫（見liquibase）
9. 由於大多數DDL語句是自動提交在大多數數據庫，最好是有每一個DDL語句SQL腳本。
10. DDL sql語句應該以某種方式運行，因此可以多次執行而不會出錯。當你可以多次編輯腳本時，真的有助於開發模式。例如，創建一個新表，只有在它不存在的情況下，或者甚至在創建新表之前創建一個表。它會幫助你處於開發模式，一個腳本沒有被釋放，改變它，清除這個腳本的md5總和，再次運行它。
11. 每個sql腳本都應該在自己的事務中運行。
12. 觸發器/程序應該在每個db 更新後刪除並創建。
13. SQL腳本保存在一個版本控制系統，如SVN
14. 腳本的名稱包含在它承諾日期，現有的（JIRA）問題ID，小描述
15. 避免在腳本中加入回滾功能（liquibase允許做那）。這使得他們寫作和支持變得更加複雜。如果您使用的每個腳本只有一個DDL語句和DML語句一個 事務中運行，甚至沒有一個腳本將不會是一個大麻煩 解決它