跟蹤對數據庫所做的更改

Question

背景：

我有一個MS SQL Server數據庫，我想跟蹤它的更改。 例如，如果需要添加或刪除列或需要刪除表。 與常規代碼的版本控制類似。

問題：

環顧四周時，我發現可以使用一些工具：

• RedGate SQL源代碼控制
• Visual Studio數據庫項目

我對知道這兩個工具中的任何一個是否可以跟蹤對我的數據庫的更改更感興趣。 更具體地說，我有一個TFS服務器，它是我的MVC代碼的源代碼控制，我可以將這兩個服務器與TFS一起使用嗎？ 它將允許我們從舊版本還原嗎？ 它將允許多個開發人員同時處理數據庫嗎？

Answer 1

對於此類工作，ApexSQL源代碼控制顯示為您所需要的。 使用此SSMS加載項，您可以直接在數據庫上工作，並且所有更改都將實時跟蹤 。

是的，幾個開發人員可以在同一數據庫上同時工作。 當一個開發人員處理一個或多個對象時，其他開發人員可以看到那些對象，並且直到第一個對象完成更改之前，其他開發人員無法更改該對象，否則將不允許它們。 無論如何，如果對象更改錯誤，則可以隨時還原以前的版本或任何早期版本。

該外接程序具有所有必要的選項和功能，以使開發人員可以在不浪費時間檢查對對象所做的更改的情況下工作，因為該外接程序會為他們執行此操作。 而且，您始終可以看到更改的對象，時間和對象。

Answer 2

我已經在數據庫版本控制領域工作了5年（擔任DBmaestro產品管理總監 ），並且已經擔任DBA超過20年了，我可以告訴你一個簡單的事實，即當您處理Java時，您不能對待數據庫對象， C＃或其他文件，並將更改保存在簡單的DDL腳本中。

原因有很多，我僅舉幾例：

• 文件存儲在本地開發人員的PC上，所做的更改不會影響其他開發人員。 同樣，開發人員不受同事所做更改的影響。 在數據庫中（通常）不是這種情況，開發人員共享同一數據庫環境，因此提交給數據庫的任何更改都會影響其他更改。
• 使用簽入/提交更改/等完成發布代碼更改（取決於您使用的源代碼管理工具）。 此時，來自開發人員本地目錄的代碼將插入到源代碼控制存儲庫中。 想要獲取最新代碼的開發人員需要從源代碼控制工具中請求它。 在數據庫中，即使沒有將其檢入到存儲庫中，更改也已經存在並且會影響其他數據。
• 在文件簽入期間，源代碼管理工具將執行沖突檢查，以查看在修改本地副本期間同一文件是否已被其他開發人員修改和簽入。 同樣，在數據庫中對此沒有檢查。 如果您在本地PC上更改了某個過程，同時又用本地PC上的代碼修改了同一過程，那么我們將覆蓋彼此的更改。
• 通過將代碼的標簽/最新版本保存到一個空目錄中，然后執行構建–編譯來完成代碼的構建過程。 輸出是二進制文件，我們在其中復制並替換現有文件。 我們不在乎以前是什么。 在數據庫中，我們無法重新創建數據庫，因為我們需要維護數據！ 部署還將執行在生成過程中生成的SQL腳本。
• 當執行SQL腳本（使用DDL，DCL，DML（用於靜態內容）命令）時，您假定環境的當前結構與創建腳本時的結構相匹配。 如果不是這樣，那么當您嘗試添加已經存在的新列時，腳本可能會失敗。
• 將SQL腳本視為代碼並手動生成它們會導致語法錯誤，數據庫依賴項錯誤，不可重用的腳本，這些使開發，維護，測試這些腳本的任務變得復雜。 此外，這些腳本可能會在與您運行的環境不同的環境中運行。
• 有時，版本控制存儲庫中的腳本與測試對象的結構不匹配，從而在生產中會發生錯誤！

還有很多，但我想您已經知道了。

我發現有效的方法如下：

1. 使用強制版本控制系統，該系統對數據庫對象執行檢出/檢入操作。 這將確保版本控制存儲庫在簽入操作中讀取對象的元數據時，與被簽入的代碼匹配，而不是作為手動完成的單獨步驟。 這還允許多個開發人員在同一個數據庫上並行工作，同時防止他們意外地覆蓋彼此的代碼。
2. 使用影響分析，該分析利用基線作為比較的一部分，以識別沖突並確定更改（在比較源代碼管理存儲庫和數據庫之間的對象結構時）是源自開發的真實更改還是源自開發的更改其他路徑，然后應跳過該路徑，例如其他分支或緊急修復。

我在此發表的一篇文章已發表在這里 ，歡迎您閱讀。

Answer 3

如果您正在尋找一種產品，該產品將自動從您的SQL Server跟蹤到TFS中的更改，我邀請您來看看我們的產品Sql Historian 。 它與大多數其他SQL版本控制系統（包括您列出的版本）不同，因為它不需要開發人員執行簽入儀式以將版本控制與已提交給數據庫的內容同步。

但是，Sql Historian和您提到的其他兩個系統具有的共同功能是：使用TFS，查看數據庫對象的舊版本的功能以及允許多個用戶同時在數據庫上使用。