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

點擊下載SQL Compare試用版

如何部署SQL Server數(shù)據(jù)庫？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

您可以不遷移就釋放數(shù)據(jù)庫嗎？

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

因此，既然我們有了一個遷移腳本，該腳本僅將精確版本移植到下一個版本，那么我們?nèi)绾螒獙赡艽嬖诘钠渌姹荆?/span>

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

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

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

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

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

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

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

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

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

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

為什么要在開發(fā)中反復構建數(shù)據(jù)庫呢？

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

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

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

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

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

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

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

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

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

遷移腳本是件好事嗎？

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

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

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

相關產(chǎn)品推薦：

SQL Prompt：SQL語法提示工具

SQL Toolbelt：Red Gate產(chǎn)品套包

SQL Monitor：SQL Server監(jiān)控工具