為什麼我應該使用 Visual Studio 2010 而不是 SSMS 進行數據庫開發？
Visual Studio 2010 引入了數據庫項目和一整套可以促進數據庫開發的相關功能。多年來，我一直使用 SQL Server Management Studio (SSMS) 進行數據庫開發，沒有出現任何問題。
- 當 SSMS 為我工作時，我為什麼要打擾 VS2010？具體來說，它比 SSMS 做得更好嗎？
- 但也許我的前提是不正確的，SSMS 在數據庫開發方面仍然勝過 VS。如果是這樣，那在哪些具體方面是真實的？
實際上，說實話，我對 VS2010 有點不知所措。我認為用於儲存過程的老式創建表腳本和文件更易於使用。如果您需要模式管理，那麼您可以花幾百美元購買 Redgate SQL Compare Pro。
如果您真的需要數據庫建模工具，那麼 Powerdesigner 甚至 Erwin 會做得更好，儘管它們並不是特別便宜。
雖然我更喜歡 SSMS，但我都使用過。一些優點和缺點：
- SSMS 有一個使用者界面，對於 SQL 開發來說“剛剛好”。僅僅建構和使用創建腳本就比 VS2010 強迫你跳過的麻煩要方便得多。更加靈活（+ SSMS）。
- VS2010 具有基本的模式管理（即差異/更新檔腳本生成）（+ VS2010）。然而，它並不是那麼好，並且有一些缺陷。例如，它匹配名稱的約束。如果您對列有檢查或預設約束但沒有命名它們，SQL Server 會在後台生成一個隨機名稱。如果您將腳本安裝在不同的機器上，這將混淆 VS2010，因為約束可能有不同的名稱。Redgate 更便宜更好。（+ VS2010，但有缺陷）。
- VS2010 真的很笨拙——你需要為每個表或其他數據庫對象創建一個文件。本質上你必須用VS2010的方式來做事，這很麻煩。(-VS2010)
- VS2010 也有些脆弱，原始碼控制集成也很不穩定。即使在一個簡單的數據庫上，每個表、約束、儲存過程、索引和其他數據庫對像都是它自己的文件。文件一直被添加到項目中，比使用（比如）C# 的典型程式項目快得多。對於樂觀並發，它傾向於在簽入不同步時默默地從項目中刪除文件。即使有良好的團隊紀律，使用者界面關於狀態的回饋也很差。這對複雜模型來說將是一場災難。（-VS2010 - 我幾乎認為這是一個大型項目的停止缺陷）。
- SSMS 與 SQL Server 一起提供 - 價格無與倫比（+ SSMS）。
- VS2010 仍然沒有像（比如）PowerDesigner 或 Oracle Designer 這樣的適當儲存庫。如果不將其安裝到數據庫中，您將無法輕鬆查詢數據模型。（-VS2010）。
總的來說，我將 VS2010 評為 B-。在一個相對簡單的數據庫項目中，它有兩個事實表和大約 15 個維度，這很笨拙。
我做過的最大的數據模型是一個法庭案件管理系統，它有大約 560 個表。對於這麼大的項目，我不會推薦 VS2010（我在 Oracle Designer 上做過）。從本質上講，它試圖變得聰明，而范式並沒有真正發揮作用。最好使用 PowerDesigner 等同類最佳的建模工具，或者僅使用手動創建表腳本。
SSMS 簡單可靠，但需要手動操作。您幾乎可以無限控制如何管理模型。將它與 Redgate SQL Compare 等模式管理器和 PowerDesigner 等體面的建模工具結合使用，您將擁有比 VS2010 更好的軟體包。
總結 除了（可能）與包含其他項目的 VS 解決方案集成之外，我不確定我是否可以引用任何殺手級功能或好處。如果您已經擁有 VS2010 高級版或終極版，那麼您的 .Net 工具鏈中就會包含一個有缺陷的數據庫開發工具。它將 DB 項目集成到您的 VS 解決方案中，因此您至少可以使用它來製作 sproc 部署腳本。
但是，VS 沒有可言的建模工具，因此 PowerDesigner 甚至 Erwin 在這方面更好。Redgate 的模式管理要好得多，SQL Compare Pro 也很便宜（大約 400 英鎊 IIRC）。恕我直言，SSMS 對 T-SQL 開發的效果要好得多，但您當然可以使用 VS2010 來實現。
VS2010 高級版並不比同類最佳的數據庫建模工具便宜多少，而 VS2010 終極版至少同樣昂貴。以與您的 VS 項目緊密集成為代價，您可能會使用第三方工具做得更好。
替代
我想如果不建議至少一種替代方案並概述其優缺點，就不應該過多地貶低 VS2010。為此，我將假設一個大型項目。雖然這些天我主要從事 A/P 工作，但我參與了一個 100 多個員工年的項目，在那裡我做了數據模型（和一些開發工作）以及其他幾個 10 年員工年的項目，我主要在那里工作作為分析師或開發人員。這些天我主要在數據倉庫系統上工作，但較大的項目主要是應用程序。根據我使用各種工具的經驗，這裡有一些關於替代工具鏈的建議：
- VS2010專業以上。您可能想要也可能不想使用高級或終極的項目管理功能。
- Subversion、AnkhSVN 和 TortoiseSVN - 任何時候都比 TFS 好，並且與 VS 配合得很好。它也非常適合從本地儲存庫中獲取並發開發工作流。
- 用於 T-SQL 開發的 SSMS - 項目管理和 SC 集成不太好，但適用於 DB 開發工作。
- 用於跟踪 sproc 文件的 VS2010 DB 項目 - 如果您使用的是 SSMS，則有點笨拙，但工作正常。它還將生成部署腳本。
- PowerDesigner - 在建模數據庫和管理數據庫模式項方面做得更好。如果您想深入了解 MDA，它也可以使用 UML。如果您想從對像模型驅動您的數據庫設計，您可以考慮使用 Sparx EA。在我見過的任何 CASE 工具中，它在 Meta CASE（可擴展元模型）方面做得最好，儘管它的數據庫建模還有一些不足之處。
- SQL Compare pro - 使用它來生成數據庫更新檔腳本或測試手動更新檔腳本（見下面的 1）。
- Framemaker - 如果您有多個分析師在研究一個規範，則比 Word 更穩定和更好的群件功能。它還支持條件包含，因此您可以隱藏 WIP 更改的規範版本版本。MIF 和 MML 使得將 API 文件和數據字典集成到規範文件中變得相當容易。這樣做非常有用，因為您可以在規範中交叉引用它們。文本標籤錨使交叉引用在重新導入時保持穩定。您還可以使用 TCS 將文件單一來源轉換為 PDF、HTML 和 CHM 輸出。
- 開源問題跟踪器 - 許多優秀的開源問題（例如 TRAC、Bugzilla 等我用過的幾個）。開源的更容易修改或集成到自定義工作流程中，而且價格無可匹敵。
- NUnit 或其他測試工具——任何最適合您要求的自動化測試工具。
- 除了 MS 項目之外的任何東西 - 被認為是有害的。MS 項目是非常內向的，它迫使項目計劃進入一個不能有效代表不確定性、風險或對利益相關者或其他第三方的依賴的模型（見下面的 2）。
**優點：**比 VS2010 更好的數據庫建模和模式管理，更好的版本控制系統，更容易自定義建構和項目工作流程，更好的規範和文件管理。
**缺點：**更多的工具集成工作，有限的數據庫集成到建構過程中。
**假設：**假設變更/發布過程的控制比數據庫模式的自動化或緊密集成的發布管理更重要。還假設自動化數據庫模式管理不是 100% 可靠的。
不是非常高科技或巧妙集成，但對於一個複雜的項目，您可能對控制比可愛的自動化功能更感興趣。我認為最好使用一組最好的工具以及集成它們所需的任何自製建構和測試腳本。試著保持建構 (a) 相對簡單易懂和 (b) 完全自動化。
- 數據庫更新檔的 QA。在大型架構上，您可能希望對實時系統進行手動修補過程，尤其是在修補程序涉及數據遷移的情況下。例如，可能需要有前滾和回滾腳本來支持在必要時撤銷更改。在這種情況下，您將需要一個工具來測試更新檔是否實際正常工作。如果您在儲存庫中管理數據庫模式，則可以通過在數據庫之前設置並從儲存庫生成參考數據庫來測試腳本。在之前的數據庫上執行更新檔腳本應該將其與儲存庫模型同步。可以使用模式比較工具對此進行測試。
- 最近我做了比定制應用程序開發更多的數據倉庫和集成工作，所以在大多數情況下，我比開發團隊更經常遇到這種情況。然而，項目管理工具和方法在管理外部利益相關者方面做得很差。在諸如數據倉庫之類的集成項目中，我真的很想看到一個項目管理工具，它在程序管理面前真正推動外部依賴關係（即我無法控制的依賴關係）。在任何重要的集成項目中，外部依賴項是迄今為止浪費時間的最大驅動因素。
自從這個問題最初發布以來，我一直在玩弄如何建構這個問題的答案。這很困難，因為 VS2010 的案例不是描述該工具的特性和優點。這是為了說服讀者從根本上改變他們的數據庫開發方法。不容易。
經驗豐富的數據庫專業人士可以回答這個問題，他們的背景涵蓋 DBA、開發人員/dba 以及 OLTP 和數據倉庫。對於我來說，一次解決數據庫開發的各個方面的問題是不可行的，因此我將嘗試為特定場景提出一個案例。
如果您的項目符合這些標準，我認為 VS2010 有一個令人信服的案例：
- 您的團隊正在使用 VS2010 進行應用程序開發。
- 您的團隊正在使用 TFS 進行原始碼控制和建構管理。
- 您的數據庫是 SQL Server。
- 您的團隊已經擁有或對 VS 自動化測試感興趣。
如果您正在評估用於數據庫開發的 VS2010，您的聖經將是來自Visual Studio ALM Rangers的Visual Studio 數據庫指南。後面沒有引用的任何引用都來自本文件。
那我們走吧……
為什麼數據庫開發過程與應用程序開發不同？
數據。如果不是因為那些討厭的數據，數據庫開發將是輕而易舉的事。我們可以在每個版本中刪除所有內容，而忘記這個麻煩的變更管理。
數據的存在使數據庫更改過程複雜化，因為當應用程序開發工作引入影響數據庫表或其他數據模式的形狀的更改時，數據通常會被遷移、轉換或重新載入。在整個變更過程中，必須保護生產質量數據和操作狀態免受可能損害其完整性、價值和對組織的有用性的變更。
SSMS 有什麼問題？
它被稱為 SQL Server Management Studio 是有原因的。作為一個獨立的工具，如果您要遵循公認的最佳實踐，那麼管理您的開發工作是不切實際的。
僅使用腳本，要將已建立的原始碼控制實踐有意義地應用到您的開發中，您將必須同時維護對象定義（例如 CREATE TABLE 腳本）和更改腳本（例如 ALTER TABLE），並努力確保它們保持同步。
用於更改表格的版本鏈很快就會變得非常愚蠢。一個非常簡單的例子：
-- Version 1 CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20)) -- Version 2 CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(50)) -- Version 3 CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(100))到版本 3，數據庫更改腳本包含：
ALTER TABLE dbo.Widget ADD Description VARCHAR(50) ALTER TABLE dbo.Widget ALTER COLUMN Description VARCHAR(100)如果這個數據庫的實時版本是版本 1，而我們的下一個版本是版本 3，那麼下面的腳本就足夠了，但是兩個 ALTER 語句都將被執行。
ALTER TABLE dbo.Widget ADD Description VARCHAR(100)5 年 4 週的 sprint 增加了一些有趣的版本腳本，並且需要額外的人工處理以盡量減少對部署時間的影響。
那麼SSMS有什麼問題嗎？不，它有利於管理和管理 SQL Server。它甚至不假裝做的是幫助數據庫開發人員完成（有時）非常複雜的管理變更任務。
如果您無法從原始碼建構數據庫的每個版本併升級到任何未來版本，那麼您的原始碼控制就會被破壞。如果您不這麼認為，請詢問 Eric Sink。
SSMS + <–插入模式比較工具–>怎麼樣？
這絕對是朝著正確方向邁出的一步，並且省去了維護腳本所需的大量手動工作。但是（這是一個很大的但是），通常涉及手動步驟。
流行的模式比較工具可以完全自動化並集成到建構過程中。但是，根據我的經驗，更常見的做法是手動執行比較，觀察生成的腳本，簽入原始碼控制，然後手動執行部署。不好。
每當我們容易犯錯的人必須參與建構或部署的過程時，我們都會引入風險，並使該過程不可重複。
如果您和您的團隊是少數擁有全自動模式比較和部署的人之一，那麼向您致敬！你們最有可能對 VS2010 提供的好處持開放態度：
- 您已經接受手動步驟是危險的。
- 你看到了自動化的價值。
- 你願意投入必要的時間讓它發揮作用。
如果您不能在一個步驟中創建建構或在一個步驟中進行部署，那麼您的開發和部署過程就會中斷。如果您不這麼認為，請詢問 Joel Spolsky。
為什麼選擇 VS2010？
@NickChammas 提出的問題是尋找殺手級功能來證明為什麼 VS2010 是數據庫開發的遊戲規則改變者。我認為我不能在此基礎上提出理由。
也許可笑的是，在其他人看到這個工具存在缺陷的地方，我看到了採用的有力理由：
- 你將不得不改變你的方法。
- 您和您的團隊將被迫以不同的方式工作。
- 您必須詳細、詳細地評估每項更改的影響。
- 您將被引導使每個更改都具有冪等性。
如果您是一個項目中唯一的 DBA，負責管理對數據庫的所有更改，那麼這種推理聽起來一定很荒謬，近乎荒謬。但是，如果您認為@BrentOzar 有道理，並且新規則之一是每個人都是 DBA，那麼您將需要以團隊中每個開發人員都可以使用的方式來控制數據庫更改。
對於某些開發人員來說，採用數據庫項目可能需要進行心理轉變（舊習慣很難改掉），或者至少需要改變流程或工作流程。已開發數據庫應用程序 的開發人員需要採用基於原始碼的方法，在這種方法中，原始碼成為對數據庫進行更改的工具。在 Visual Studio 數據庫項目中，項目和原始碼是數據庫架構的“真實版本”，並使用 SCM 工作流進行管理，開發人員或組織可能已經將其用於其應用程序堆棧的其他部分。對於數據，生產數據庫仍應保持其“真實版本”。
我們已經實現了成功採用 VS2010 方法進行數據庫開發所必需的根本轉變……
將您的數據庫視為程式碼
不再更改實時數據庫。每個數據庫更改都將遵循與應用程序更改相同的模式。修改原始碼、建構、部署。這不是微軟暫時改變方向，這是 SQL Server 的未來。數據庫即程式碼將繼續存在。
數據庫開發人員為應用程序的版本定義對象的形狀，而不是如何將數據庫引擎中的現有對象更改為所需的形狀。您可能會問自己：如何針對已經包含客戶表的數據庫進行部署？這就是部署引擎發揮作用的地方。如前所述，部署引擎將獲取架構的編譯版本並將其與數據庫部署目標進行比較。差異引擎將生成必要的腳本來更新目標模式以匹配您從項目中部署的版本。
是的，還有其他工具遵循類似的模式，對於我對答案的限制之外的項目，它們值得同等考慮。但是，如果您使用 Visual Studio 和 Team Foundation Server ALM，我認為它們無法與之競爭。
VS2010 數據庫項目有什麼問題？
編輯：那你的意思是什麼？
@AndrewBickerton 在評論中提到我沒有回答最初的問題，所以我將嘗試總結“為什麼我應該使用 Visual Studio 2010 而不是 SSMS 進行數據庫開發？” 這裡。
- SSMS 不是數據庫開發工具。是的，您可以使用 SSMS 開發 TSQL，但它不提供 VS2010 的豐富 IDE 功能。
- VS2010 提供了一個框架來將你的數據庫視為程式碼。
- VS2010 為您的數據庫程式碼帶來了靜態程式碼分析。
- VS2010 為您提供了完全自動化建構-部署-測試週期的工具。
- SQL2012 和 Visual Studio vNext 擴展了數據庫項目的功能。立即熟悉 VS2010，您將在下一代數據庫開發工具上搶占先機。