SQL Compare是一款比較和同步SQL Server數據庫結構的工具。現有超過150,000的數據庫管理員、開發人員和測試人員在使用它。當測試本地數據庫，暫存或激活遠程服務器的數據庫時，SQL Compare將分配數據庫的過程自動化。

點擊下載SQL Compare試用版

如何部署SQL Server數據庫？

曾經有一段時間，使用RDBMS的唯一方法是在使用大容量復制實用程序輸出其數據之后，將現有版本脫機，然后從執行的一個腳本中創建新版本以創建數據庫。然后，用導出的數據填充數據庫，最后使系統恢復在線狀態。如何使用單個腳本達到這一點是另一回事。它可能最初是從實體關系圖表工具或某些其他設計工具生成的輸出。如果有更簡單，更可靠的方法，即使是最狂熱的數據庫設計人員也不會手工剪切表構建腳本。

該ALTER TABLE命令稍后發布到SQL。這為數據庫開發人員提供了在保留其數據的同時選擇更改現有數據庫的機會，盡管只有少數情況下，RDBMS可以在沒有補充腳本的情況下做到這一點。如果使用了這種“遷移”腳本，那么會同時更改匹配的構建腳本，以便隨后可以從頭開始創建“更改的”對象。

如今，開發和部署數據庫的方式取決于應用程序和設置的類型。零售銀行或政府部門將不會容忍某些“初創”文化的做法。但是，任何組織都普遍認為，必須有可能從源代碼構建數據庫，該源代碼存放在團隊可見的存儲庫中。除此之外，開發團隊還應擁有選擇最合適的開發和發布系統的自由。

我建議，盡管現有數據庫應用程序的發布過程應以測試和使用一個或多個保留現有數據的遷移腳本為主導，但是常規的自動構建是開發數據庫最快，最省心的方式，只要記錄并解決了每個潛在的數據遷移問題，便可以解決問題。

一個團隊如何在沒有“敲頭”的情況下一起完成一個腳本？

使用單個構建腳本文檔，很容易與更新產生沖突，這些更新會干擾其他開發人員的并發工作。解決方案是使用SQLCMD腳本，該腳本以正確的順序提取所需數量的獨立文件。然后，您可以像往常一樣使用源代碼控制來跟蹤每個對象的演變。該-i命令行選項允許你指定的文件列表。SQLCMD在按照指定的順序執行它們之前檢查它們是否全部存在。每個組件文件都可以放在源代碼管理中。由于每個文件都可以依次列出:r<filename>在文件中使用SQLCMD命令，即使使用最復雜的數據庫，也不會被迫擁有大型腳本文件，并且可以保證以指定的正確順序執行它們。使用遷移腳本，每個發行版都需要自己的腳本，并且只能用于從一個版本遷移到下一個“目標”版本。這在源代碼管理中，并且像其他任何文件一樣對待。可以輕松地將它們鏈接在一起，以將目標移動到多個版本級別。

為什么這些單獨的腳本文件必須全部按順序排列？

甚至表也取決于所定義的其他SQL Server組件。例如，當您擁有UDT（用戶定義的數據類型）時，需要在表之前放置這些UDT。在還創建它們引用的對象之前，不能創建函數。您需要在創建的表中放置所有約束和引用，因此易于理解設計，這意味著通常需要以正確的依賴關系順序來構建表。這些僅僅是示例。出于不同的原因，必須按順序對遷移文件進行排序：如果您需要移動一個現有數據庫多個版本步驟。按照慣例，遷移腳本會從一個版本轉移到另一個版本。要升級兩個版本步驟，請先遷移到下一個版本，然后再遷移到下一個版本。

我不能僅將自己限制在不引起依賴關系的SQL Server對象上嗎？UDT和函數畢竟有點深奧。

您將不是第一個嘗試這樣做的人，但是也許您將是第一個成功的人。無論如何，祝你好運。

如何以正確的順序獲取所有源文件？

如果您繼承了混亂，則取決于混亂程度。如果您已經擁有最新的工作數據庫，則可以使用SSMS生成一個單文件構建腳本，該腳本將告訴您正確的順序。如果沒有當前的數據庫構建，如果將所有文件放在一個目錄中，則完全有可能使SQL Compare從混亂（源）生成單個文檔構建腳本（目標）。您只需將凌亂的目錄與空數據庫同步，或/empty2在SQL Compare中使用方便的開關即可。

如果您將源文件夾和目標文件夾都設置為腳本文件夾，則它將源目錄中的混亂情況帶入目標文件夾中，并且將它們整齊地整理。在使用它時，它甚至可以像您的母親一樣工作，可以通過將每個表和例程的源代碼分別整齊地放置在一個目錄中（每個類型的數據庫對象都有一個子目錄，每個數據庫對象一個文件）來清理原始混亂。表或其他類型的數據庫對象：（同時使源和目標成為源目錄）。

無論選擇哪種方式獲取單個文檔構建腳本，都會告訴您構建數據庫的正確順序。然后，您只需要創建一個SQLCMD文件即可，該文件指定了正確的腳本執行順序，并且有了修改和擴展數據庫的基礎。像SQL Change Automation這樣的工具也可以讓您建立腳本的部署順序，但是您必須更改文件名。無論如何，您都可以直接從該目錄進行構建，并且可以插入任何必要的DML腳本。相似文件可以依次管理一組遷移腳本，以將新版本發布到生產環境。

為什么不繼續從所有腳本文件生成單文檔構建腳本呢？

時間，精力和可重復性。如果需要，熟練的數據庫開發團隊不會考慮每天幾次重建數據庫。前幾天，我在一小時內建立了一個數據庫二十次。這意味著他們可以很快地掉頭解決設計錯誤，從而減少了嘗試不同策略或使用導致更多依賴關系的功能時受到的抑制。即使不是很重要，他們也要定期進行操作，以便第一個知道依賴關系變化的人。

當您使用SQL Compare創建單文檔腳本時，它不只是執行SQL文件，還會解析這些文件，使用它們構建源數據庫的模型，然后將其與目標數據庫進行比較。然后，它生成自己的SQL，以使目標與源相同。對于構建而言，這無關緊要，即使任何DML（例如添加擴展屬性，插入參考數據或枚舉）都將丟失。但是，在創建部署腳本時，狡猾的遷移步驟將不再存在。

遷移腳本方法解決的所有那些問題呢？

數據庫構建沒有任何此類問題。遷移腳本解決了在保留現有數據的同時更新現有數據庫的問題，而不是構建數據庫的問題。從頭開始建立數據庫然后將數據放入其中要比在其中存放數據要容易得多，就像在居民搬進來之前蓋房子要容易一樣。遷移就像蓋一棟房子。房屋擴建，房屋仍被占用；可能性差不多，但這是另一個問題。另外，如果使用ALTER TABLE語句升級數據庫，則需要進行額外的工作，以確保更改也反映CREATE在源代碼管理的構建腳本中。

那為什么還要擔心遷移呢？

遷移對于部署很重要。一旦完成測試，并且團隊對于發布候選版本適合發布并因此準備好進行部署管道（測試，UAT，登臺等）感到高興，他們就需要創建并徹底測試遷移腳本。

此遷移腳本僅在將數據庫從一個精確版本更改為另一精確版本時有用。當您準備進行發布時，您將專注于執行遷移腳本。SQL Compare可以自動生成一個初次遷移的腳本，但是如果您完成了重命名表或重新設計整個數據模型之類的尷尬事情，那么不可避免的是，您必須手動剪切一些代碼以使其包含在內。保留現有數據。這將需要測試，并且其中一些測試將需要在暫存中。

您可以不遷移就釋放數據庫嗎？

曾經有一次只能建立SQL數據庫，而不能更改。在那些日子里，我們必須使應用程序脫機，導出數據，然后將數據導入新版本，然后再使其重新聯機。如果數據模型已更改，則需要一個特殊的例程來保存數據，以便可以將其導入新的表結構中，或者以導出格式（例如CSV）更改數據。您也可以將數據導入到同一服務器上現有數據庫的臨時版本中，并根據需要遷移數據，對數據進行切片和切塊以適應新模型。在整個應用程序脫機的情況下，您將等待，鼓動手指并嘗試忽略電話，而數據仍在滑動，您希望不會出現故障。

因此，既然我們有了一個遷移腳本，該腳本只將精確版本帶到下一個版本，那么我們如何應對可能存在的其他版本？

每個候選候選版本都帶有一個遷移腳本，該腳本將采用生產數據庫或任何存儲有數據的數據庫，從當時存在的生產版本到候選候選版本。為了脫離其他版本，請依次為每個版本應用遷移腳本。

哇，所以我可以一個接一個地應用每個遷移腳本來從頭開始構建數據庫！

如果按順序執行它們并具有完整的設置，它將這樣做，但是遷移腳本的重點是保留現有的應用程序數據。當包含第一個版本的現有表中的數據甚至不存在時，您將如何從中獲取數據？

不。您要做的就是概括每個失敗的設計錯誤和更正，而您將沒有數據。另一個問題是，任何構建腳本都應該成功執行，否則就不會留下任何痕跡。這通常意味著在事務內進行操作，但是即使這樣事情也會變得復雜，有時您必須在事務外進行部分操作。在這種情況下，您必須“撲朔迷離”。如果將一系列遷移腳本應用在字符串中，則它們必須整齊地失敗，以便它們像啟動前一樣離開數據庫。這不容易。

除非您還將每個更改都保存到對象的CREATE腳本中，否則您將無法從源代碼管理中受益，因為他們知道誰做了什么，何時做以及為什么做。您無法從遷移腳本中獲得此信息。這是基本的問責制和監督。您如何對表的更改進行審核跟蹤？

是的，但是在開發中使用遷移腳本似乎要簡單得多

如果您是單個開發人員，則使用生產數據的副本，那么可以。但是，大多數數據庫開發人員都需要通過調整代碼來犯錯，嘗試一下并優化性能。如果每個步驟都是一個遷移文件，那么這些文件將不可避免地堆疊在一起。在一個發行版中包含數百個遷移文件并不鮮見。在某些時候，您必須將它們合并為一個遷移。然后，您在該項目上還有另一個開發人員。您無意中更改了相同的遷移步驟，因為您倆都在處理重要的表或過程集。然后，您必須通過合并兩個分支來解決這些沖突。然后，您發現該應用程序具有人員的姓名和地址，也許其他詳細信息未加密。

即使您解決了所有這些問題并確定了如何在源代碼管理中維護源代碼，將遷移腳本與更新后的數據應用于生產服務器時，仍然可能會陷入困境。典型的例子是Null或O'Brien家族的成員同時注冊使用您的系統。

您如何處理表結構中的更改，這些更改將導致數據不再導入？

當您對一個或一組表進行“重大更改”時，您將準備，測試并執行準備數據的遷移代碼。這可能是數據存儲位置的更改，但很可能是處理CHECK約束的更改，列可為性（NULL to NOT NULL）的更改或額外的唯一約束或外鍵。您執行代碼來修復數據，并確保將其放置在新構建的正確位置和格式中。然后，將代碼添加到文件中，該文件將成為下一個版本的遷移腳本。

然后，您將數據另存為下一個構建的新構建數據。下次常規構建可能會出錯，但是沒有人受傷。在準備遷移腳本時，這些錯誤都是有價值的見解。

為什么要在開發中反復構建數據庫呢？

即使只處理一個版本或數據庫變體，也可能至少有兩個數據庫副本在開發中。您將擁有一份副本，可以在無法打擾他人，拆除，重建和試驗的情況下犯下難以言喻的罪行。您將擁有另一個共享的資源，可用于對已簽入的更改進行回歸測試。您可能還有其他具有不同數據集或變體的對象。一切都必須與簽入的源代碼保持最新。您將擁有不同的標準數據集，因為畢竟，測試端到端流程的最快方法是從一組定義的數據開始，然后查看是否得出正確的結果。

您還必須與應用程序開發保持同步。通常，數據庫只是應用程序的一小部分。如果整個應用程序的開發人員都在進行或測試重大更改，則需要提供至少一個數據庫副本以與進度保持同步，尤其是在應用程序與數據庫緊密耦合的情況下，尤其如此。直接訪問表。他們將要測試他們的代碼，以使其支持并正在構建的數據庫逐步升級。它可能與您正在嘗試的步驟版本不同。

我的數據庫是如此龐大，以至于我無法從頭開始構建。我必須遷移它

構建過程必須完全自動化和優化，因為它過程緩慢且乏味。此外，正如我的數字朋友不斷提醒我的那樣，人類在疲倦時容易出錯。插入數據可能是一個緩慢的過程，但是如果您在禁用約束的情況下使用本機BCP，則數據庫的大小必須相當合理才能超過過夜的構建。您很快會發現，開發周期自然屬于使用夜間構建的情況。如果您的開發團隊處于截然不同的時區，這可能很尷尬，但是我發現總是有一個“死角”可以安排常規構建。

即使開發數據庫太大而無法進行一整夜的構建，也不必擔心。這不是一個新問題，并且有解決方案。大多數數據庫保存的數據對于數據庫的運行是完全不必要的。我從來沒有找到一個數據庫，其中沒有大量的無用和未引用的信息，甚至是圖像數據，都在其中揮霍。我們稱其為“臥室碗櫥綜合征”。答案是先加載基本信息。然后，您可以使數據庫可用。然后，按其有用性將其余部分作為后臺進程加載。沒有人會注意到。人類通常僅出于舒適性價值而保留數據。

構建腳本和遷移腳本之間到底有什么區別？

構建腳本和遷移腳本都將數據庫從一個版本移植到另一個版本。唯一的區別是，構建腳本將其從基巖遷移到所需版本，同時忽略任何現有數據，因為在此階段沒有任何數據，而遷移腳本保留了現有數據并在兩個版本之間對數據進行了必要的更改。通常，將構建腳本包裝在事務中仍然是一種好習慣，但通常不是這樣，因為在發生錯誤后很容易將其刪除。遷移腳本需要回滾和冪等（即，無意中再次運行它不會造成損害）

我正在努力找出同步腳本和遷移腳本之間的區別？

術語“同步”具有誤導性。數據同步通常意味著將所有同步節點上的數據操作傳遞到其他節點。如果您在移動設備上放了新的MP3，它會出現在筆記本電腦上，反之亦然。如果您在筆記本電腦上刪除該Rick Astley單曲，它將在移動設備上被刪除。數據庫同步腳本使目標數據庫與源數據庫相同，同時保留其現有數據，反之亦然。遷移腳本從一個版本到下一個版本增量獲取數據庫及其數據。沒有太大的區別。傳統上，遷移腳本傾向于“手工切割”，而同步腳本傾向于由第三方工具生成。它們對錯誤回滾具有相同的要求。

那么，遷移腳本是件好事嗎？

好？如果要升級現有的實時系統，則它們在部署管道中始終是必不可少的。您使用它們的次數越多，您生產的無故障版本就越有可能。但是，在選擇候選版本之前，數據庫開發本身通常要好得多，并且構建起來會更加靈活。

總結？

數據庫開發人員的任務是使他人的生活盡可能輕松。這意味著要盡早考慮部署，安全，維護，培訓，監督和合規性問題。為此，數據庫必須處于對象級別的源代碼控制中，以便更廣泛的團隊可以及早檢查潛在問題，并可以跟蹤更改。每次計劃要發布到生產數據庫系統的發行版時，都必須在源代碼控制中附帶一個遷移腳本，該腳本將安全地將生產版本升級到新發行版。因此，必須為數據庫標記正確的版本號，以防止發生意外。

我建議定期建立數據庫，通常是在一夜之間建立，但如有必要，可以更定期地建立數據庫。我建議在開發中使用干凈的例行構建，而不是為此例行構建創建并應用新的遷移腳本，這既是因為它省去了不必要的工作，又因為它鼓勵使用標準數據集進行例行回歸測試。但是，開發人員需要在發布之前仔細標記潛在的數據遷移問題，因此在需要腳本之前就先進行遷移腳本的工作。無論何時簽入“重大更改”，他們都會使用許多常規例程所需的例程來準備數據。

相關產品推薦：

SQL Prompt：SQL語法提示工具

SQL Toolbelt：Red Gate產品套包

SQL Monitor：SQL Server監控工具