データベース開発にSSMS経由でVisual Studio 2010を使用する必要があるのはなぜですか？

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が混乱します。レッドゲートは安くて優れています。（+ VS2010、ただし欠陥あり）。

• VS2010は本当に不器用です。テーブルまたは他のDBオブジェクトごとに1つのファイルが必要です。基本的に、VS2010の方法で処理する必要がありますが、これは非常に面倒です。（-VS2010）

• VS2010も多少脆弱であり、ソース管理の統合は不安定です。単純なデータベースでも、すべてのテーブル、制約、ストアドプロシージャ、インデックス、その他のデータベースオブジェクトは独自のファイルです。ファイルはプロジェクトに常に追加され、C＃を使用した一般的なプログラミングプロジェクトよりもはるかに高速です。楽観的な同時実行では、チェックインの同期が外れると、プロジェクトからファイルを静かにドロップする傾向があります。チームの規律が優れていても、ステータスに関するUIからのフィードバックは非常に貧弱です。これは、複雑なモデルでは災害になります。（-VS2010-大規模なプロジェクトにとっては目を奪われるような欠陥だとほとんど思います）。

• SSMSにはSQL Serverが付属しています-価格に勝てません（+ SSMS）。

• VS2010には、PowerDesignerやOracle Designerなどの適切なリポジトリがまだありません。データベースにインストールしないと、データモデルを簡単にクエリすることはできません。（-VS2010）。

全体として、私はVS2010をB-について評価します。2つのファクトテーブルと約15次元の比較的単純なデータベースプロジェクトでは不器用でした。

私がこれまでに行った最大のデータモデルは、約560のテーブルを持つ裁判所管理システム用でした。VS2010は、そのサイズのプロジェクトにはお勧めしません（Oracle Designerで行いました）。本質的には巧妙にしようとしていますが、パラダイムはあまりうまくいきません。PowerDesignerのような最高級のモデリングツールを使用するか、手動でテーブルスクリプトを作成するだけでよいでしょう。

SSMSはシンプルで信頼性がありますが、手動です。モデルをどのように管理するかについては、ほぼ無限に制御できます。Redgate SQL Compareなどのスキーママネージャーや、おそらくPowerDesignerなどの適切なモデリングツールと組み合わせると、VS2010よりもはるかに優れたパッケージが得られます。

まとめ 他のプロジェクトを含むVSソリューションとの統合（おそらく）とは別に、キラー機能や利点を引用できるかどうかはわかりません。既にVS2010 PremiumまたはUltimateをお持ちの場合は、.Netツールチェーンに多少欠陥のあるデータベース開発ツールが組み込まれています。DBプロジェクトをVSソリューションに統合するため、少なくともsprocデプロイメントスクリプトを作成するために使用できます。

ただし、VSには言及できるモデリングツールがないため、PowerDesignerまたはErwinがその点で優れています。Redgateのスキーマ管理ははるかに優れており、SQL Compare Proは非常に安価です（約400ポンドのIIRC）。IMHO SSMSは、T-SQL開発でははるかに優れた機能を発揮しますが、VS2010で確実に実行できます。

VS2010プレミアムは、最高のデータベースモデリングツールよりも安くはありません。VS2010Ultimateは、少なくとも同じくらい高価です。VSプロジェクトとの緊密な統合を犠牲にして、おそらくサードパーティのツールを使用してより良い結果を得ることができます。

代替案

VS2010から少なくとも1つの代替案を提案し、その長所と短所を概説せずに、あまりスラグにしないでください。この目的のために、大規模なプロジェクトを想定します。私は最近、主にA / Pの仕事をしていますが、データモデル（およびいくつかの開発作業）を行った100年以上のスタッフ年プロジェクトと、10年のスタッフ年の範囲で他のいくつかのプロジェクトに参加しました。アナリストまたは開発者として。最近はほとんどデータウェアハウスシステムに取り組んでいますが、大きなプロジェクトは主にアプリケーションでした。さまざまなツールでの私の経験に基づいて、代替ツールチェーンのいくつかの提案を以下に示します。

• VS2010プロフェッショナル以上。PremiumまたはUltimateのプロジェクト管理機能を使用する場合と使用しない場合があります。
• Subversion、AnkhSVNおよびTortoiseSVN-いつでもTFSよりも優れており、VSでうまく動作します。また、並行開発ワークストリーム用のローカルリポジトリからのファーミングにも非常に適しています。
• T-SQL開発用のSSMS-プロジェクト管理とSC統合はあまり良くありませんが、DB開発作業には適しています。
• sprocファイルを追跡するためのVS2010 DBプロジェクト-SSMSを使用しているが正常に動作している場合は少し不器用です。また、展開スクリプトも生成します。
• PowerDesigner-データベースのモデル化とDBスキーマアイテムの管理の改善。また、MDAに重点を置きたい場合にもUMLを実行します。オブジェクトモデルからDB設計を推進する場合は、代わりにSparx EAを検討できます。データベースモデリングは、何か必要なものを残していますが、これまで見てきたどのCASEツールのMeta CASE（拡張可能なメタモデル）でも最高の仕事をします。
• SQL Compare pro-これを使用して、DBパッチスクリプトを生成するか、手動パッチスクリプトをテストします（以下の1を参照）。
• Framemaker-複数のアナリストが仕様に取り組んでいる場合、Wordよりもはるかに安定した優れたグループウェア機能。また、条件付き包含もサポートしているため、WIPの変更を非表示にして、仕様のバージョン付きリリースを作成できます。MIFとMMLを使用すると、APIドキュメントとデータディクショナリを仕様ドキュメントに簡単に統合できます。これは、仕様で相互参照できるため、非常に便利です。テキストラベルアンカーにより、再インポート全体で相互参照が安定します。TCSを使用して、ドキュメントをPDF、HTML、およびCHM出力に単一ソース化することもできます。
• オープンソースの問題追跡ツール-多くの優れたオープンソースの問題追跡ツール（たとえば、TRAC、私が使用したカップルの名前を示すBugzilla）。オープンソースのものは、変更やカスタムワークフローへの統合が容易であり、価格に勝るものはありません。
• NUnitまたは他のテストツール-要件に最も適した自動テストツールは何でも。
• MSプロジェクト以外-有害と見なされます。MSプロジェクトは非常に内向きであり、プロジェクト計画を、不確実性、リスク、または利害関係者または他の第三者への依存を効果的に表さないモデルに強制します（以下の2を参照）。

長所： VS2010よりも優れたデータベースモデリングとスキーマ管理、より優れたバージョン管理システム、ビルドとプロジェクトのワークフローのカスタマイズの容易化、仕様とドキュメントのより優れた管理。

短所：ツールを統合するためのさらなる努力、ビルドプロセスへの限定的なDB統合。

仮定： DBスキーマの自動化または緊密に統合されたリリース管理よりも重要な変更/リリースプロセスの制御を想定しています。また、自動化されたDBスキーマ管理は100％信頼できるものではないと想定しています。

それほど高度なハイテクや洗練された統合ではありませんが、複雑なプロジェクトでは、おそらく自動化されたかわいい機能よりも制御に興味があります。最高のブリードツールのセットと、それらを統合するために必要な自家製のビルドとテストのスクリプトがあれば、より良い状態になっていると思います。（a）理解するのが比較的簡単で、（b）完全に自動化するようにしてください。

1. DBパッチのQA。大規模なスキーマでは、特にパッチにデータ移行が含まれる場合、稼働中のシステムに手動でパッチを適用するプロセスが必要になる場合があります。たとえば、必要に応じて変更のバックアウトをサポートするために、ロールフォワードおよびロールバックスクリプトを使用することが望ましい場合があります。この場合、パッチが実際に正しく機能することをテストする機能が必要になります。リポジトリでデータベーススキーマを管理する場合、データベースの前にセットアップし、リポジトリから参照データベースを生成することにより、スクリプトをテストできます。beforeデータベースでパッチスクリプトを実行すると、リポジトリモデルと同期するはずです。これをテストするには、スキーマ比較ツールを使用できます。

2. 最近、カスタムアプリケーション開発よりも多くのデータウェアハウスと統合作業を行っているため、ほとんどの場合、開発チームが行うよりも頻繁にこれに遭遇します。しかし、プロジェクト管理ツールと方法論は、外部の利害関係者を管理するという非常に貧弱な仕事をします。データウェアハウスなどの統合プロジェクトでは、プログラム管理に直面して外部の依存関係（つまり、制御できないもの）を実際にプッシュするプロジェクト管理ツールが必要です。自明ではない統合プロジェクトでは、外部依存関係が無駄な時間の最大の要因です。

もともと投稿されて以来、私はこの質問に対する答えをどのように構成するかをいじっていました。VS2010の場合はツールの機能と利点を説明するものではないため、これは困難です。これは、読者にデータベース開発へのアプローチを根本的に変えるよう説得することです。簡単ではありません。

DBA、開発者/ dba、およびOLTPとデータウェアハウジングの両方にまたがるバックグラウンドミックスで、ベテランデータベースプロフェッショナルからのこの質問に対する回答があります。データベース開発のすべての面で一度にこれにアプローチすることは現実的ではないため、特定のシナリオについてケースを作成してみます。

プロジェクトがこれらの基準に適合する場合、VS2010には説得力のあるケースがあると思います。

• チームはアプリケーション開発にVS2010を使用しています。
• あなたのチームはソース管理とビルド管理にTFSを使用しています。
• データベースはSQL Serverです。
• あなたのチームは、VS自動テストをすでに持っているか、または興味を持っています。

あなたはデータベース開発のためのVS2010を評価している場合は、あなたのバイブルになりますVisual Studioのデータベース・ガイドからのVisual Studio ALMレンジャーズ。参照のない引用は、このドキュメントからのものです。

じゃあ行って...

データベース開発プロセスがアプリケーション開発と異なるのはなぜですか？

データ。その厄介なデータがなければ、データベースの開発は楽勝になります。すべてのリリースですべてを削除し、この面倒な変更管理を忘れることができました。

データベースのテーブルやその他のデータスキーマの形状に影響を与えるアプリケーション開発作業によって変更が導入されると、データはしばしば移行、変換、または再読み込みされるため、データの存在はデータベース変更プロセスを複雑にします。この変更プロセス全体を通じて、生産品質データと運用状態は、組織に対する整合性、価値、および有用性を危険にさらす可能性のある変更から保護する必要があります。

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週間のスプリントでは、いくつかの面白いバージョンのスクリプトが追加され、展開時間への影響を最小限に抑えるために追加の人手が必要になります。

SSMSに問題はありますか？いいえ、SQL Serverの管理と管理に適しています。それがするふりをしてさえいないのは、データベース管理者が変更を管理する（時には）非常に複雑なタスクを支援することです。

データベースのすべてのバージョンをソースからビルドして、将来のバージョンにアップグレードできない場合、ソース管理が破損します。そう思わない場合は、エリックシンクにお問い合わせください。

SSMS + <-スキーマ比較ツールの挿入->はどうですか？

これは間違いなく正しい方向への一歩であり、スクリプトを維持するために必要な手作業の多くを取り除きます。しかし（そしてそれは大きなですが）、通常は手動の手順が必要です。

一般的なスキーマ比較ツールは、完全に自動化してビルドプロセスに統合できます。ただし、私の経験では、より一般的な方法は、比較を手動で実行し、結果のスクリプトを目で確認してソース管理にチェックインし、手動で実行して展開することです。良くない。

フォールチブルな人間がビルドまたは展開のプロセスに関与しなければならないときはいつでも、リスクをもたらし、プロセスを繰り返し不可能にします。

あなたとあなたのチームが、完全に自動化されたスキーマの比較と展開を行っている数少ない人たちの中にいるなら、あなたに気を配ってください！皆さんは、VS2010が次のようなメリットを提供することに最も敏感です。

• 手動の手順は危険であることを既に受け入れています。
• 自動化の価値がわかります。
• あなたはそれを機能させるのに必要な時間を喜んで投資します。

単一のステップでビルドを作成できない場合、または単一のステップで展開できない場合、開発および展開プロセスは中断されます。そう思わない場合は、ジョエル・スポルスキーに聞いてください。

VS2010を選ぶ理由

@NickChammasが提起した質問は、VS2010がデータベース開発のゲームチェンジャーである理由を示すキラー機能を探しています。私はその根拠に基づいて主張することはできないと思います。

おそらくコミカルに、他の人がこのツールに欠陥を見つけた場合、採用の強力な理由がわかります：

• アプローチを変更する必要があります。
• あなたとあなたのチームは別の方法で働くことを余儀なくされます。
• すべての変更の影響を詳細に詳細に評価する必要があります。
• すべての変更がべき等になるように導かれます。

あなたがプロジェクトの唯一のDBAであり、データベースへのすべての変更を管理している場合、この推論はばかげたことにばかげているように聞こえるはずです。しかし、@ BrentOzarにポイントがあり、新しいルールの1つがEverybody's the DBAであると考える場合、チームのすべての開発者が作業できるようにデータベースの変更を制御する必要があります。

データベースプロジェクトの採用には、一部の開発者または少なくともプロセスまたはワークフローの変更のために、メンタルシフト（古い習慣を壊すのが難しい）が必要になる場合があります。運用データベースがデータベースの現在のバージョンを表すデータベースアプリケーションを開発した開発者は 、ソースコードがデータベースに変更を加える手段となるソースコードベースのアプローチを採用する必要があります。Visual Studioデータベースプロジェクトでは、プロジェクトとソースコードはデータベーススキーマの「真実の1つのバージョン」であり、開発者や組織がアプリケーションスタックの他の部分で既に使用しているSCMワークフローを使用して管理されます。データについては、実稼働データベースは本来あるべき「真実の1つのバージョン」のままです。

データベース開発にVS2010アプローチをうまく採用するために必要な基本的な変化に到達しました…

データベースをコードとして扱う

ライブデータベースを変更する必要はありません。すべてのデータベースの変更は、アプリケーションの変更と同じパターンに従います。ソースの変更、ビルド、デプロイ。これはMicrosoftからの一時的な方向転換ではありません。これはSQL Serverの未来です。データベースとしてのコードはここにあります。

データベース開発者は、データベースエンジン内の既存のオブジェクトを目的の形状に変換する方法ではなく、アプリケーションのバージョンに対してオブジェクトの形状を定義します。自問自答しているかもしれません：顧客テーブルが既に含まれているデータベースに対してこれをどのように展開しますか？これは、展開エンジンが登場する場所です。前述のように、デプロイメントエンジンはスキーマのコンパイル済みバージョンを取得し、データベースデプロイメントターゲットと比較します。差分エンジンは、プロジェクトから展開しているバージョンと一致するようにターゲットスキーマを更新するために必要なスクリプトを生成します。

はい、同様のパターンに従う他のツールがあり、私が答えに課した制約の範囲外のプロジェクトについては、同等に考慮する価値があります。ただし、Visual StudioとTeam Foundation Server ALMを使用している場合、それらが競合できるとは思いません。

VS2010データベースプロジェクトの何が問題になっていますか？

• 彼らは完璧ではありません。ただし、制限と問題のある領域を認識している場合は、それらを回避できます。
• 複雑なデータの移動には依然として注意と注意が必要ですが、展開前/展開後のスクリプトで対応します。

編集：それでは、あなたのポイントは何ですか？

@AndrewBickertonはコメントで、元の質問には答えていないと述べたので、「データベース開発にSSMSではなくVisual Studio 2010を使用する必要があるのか​​？」ここに。

• SSMSはデータベース開発ツールではありません。はい、SSMSでTSQLを開発できますが、VS2010の豊富なIDE機能は提供しません。
• VS2010は、データベースをコードとして扱うためのフレームワークを提供します。
• VS2010は、データベースコードに静的コード分析をもたらします。
• VS2010は、ビルド-デプロイ-テストサイクルを完全に自動化するツールを提供します。
• SQL2012およびVisual Studio vNextは、データベースプロジェクトの機能を拡張します。VS2010に今すぐ慣れれば、次世代のデータベース開発ツールをすぐに使い始めることができます。

VSは、SSMSを知らない場合、またはサードパーティのツールを使用したことがある場合に表示される場合があります。スキーマの比較などにRed Gateツールを使用すると、VSのギャップが際立ちます。また、無料のSSMSプラグインも使用します。

ソース管理ビットは誤解を招く可能性があります。実稼働データベースにあるのは参照コピーです。開発者が使用しているものではありません。見る

• https://stackoverflow.com/q/1597085/27535
• https://stackoverflow.com/q/4433153/27535

SSRSレポートデザインおよびSSISパッケージには、Visual Studioを広く使用しています（まあ、BIDS）。Management Studioでは、まったくできなかったとしても、まったくできませんでした。Visual Studioは、はるかに完全で統合された開発環境であり、ソース管理システムとの連携もはるかに優れています。そして、それはすべて価格に反映されています！

正直に言うと、データベースの設計、開発、および（明らかに）管理のために、私の投票はSQL Server Management Studioに直接送られます。入力するのは簡単です：

create table newTable
(
    someId int identity(1, 1) not null primary key clustered,
    ...... you get the idea
)

次に、すべての適切な場所をクリックします。SSMSは素晴らしいレイアウトであり、作業するのは絶対に楽しい作業です。そして、私は本質的に.NETソフトウェア開発者です。しかし、データベースの設計とコーディングに関しては、SSMSを10回のうち11回選択します。

ベストプラクティスはありませんが、VS 2010データベースプロジェクトとソースコードコントローラー（VSS 2010、Subversionなど）を使用すると、データベースをバージョン管理できます。

最初にデータベースをSSMSに直接設計することをお勧めします。データベースの準備がほぼ完了したら、VS 2010データベースプロジェクトにインポートします。インポートが完了したら、データベースプロジェクトに常に新しいスクリプトを追加して、すべての変更を追跡する必要があります。データベースプロジェクトの比較機能を使用して、開発サーバーからすべての変更を取得し、それらのすべてのスクリプトをプロジェクトに直接インポートできます。これで、ソースコードコントローラーに変更を「コミット」するだけです。

この方法を使用すると、バージョン管理されたデータベースを使用できます。各変更のバージョンを見つけて、変更をロールバックできます。

これが唯一の利点ではありません。この種のプロジェクトでは、データベースをプロジェクトと比較して変更をスクリプト化し、SQL PowerShellコマンドプロンプトを使用して、すべてのデータベースを同じスクリプトで更新できます。このスクリプトはデータベースのXMLスキーマです。データベースを更新するために必要なコマンドのみを実行します。データベースで単体テストを行うこともできます。データベースプロジェクトに関するその他の優れた記事はこちらから入手できます。デプロイ機能を使用すると、プリスクリプトとポストスクリプトを使用できます。これらのスクリプトを使用すると、検証を行ったり、システムテーブルにデータを挿入したりできます。

ここでは、データベースプロジェクトのためのステップの手順により、良好なステップです。

SQL Serverのインストール時にSSMSが存在するため、VS2010よりもSSMSを使用しています。それはおそらく、SSMSがVS2010、IMHOよりも多く使用される最も重要なことです。

また、Red-Gateなどのベンダーは、SSMSと統合するツールを開発しているが、必ずしもVS2010とは限らないことも発見しました。これは、MicrosoftにはないSSMSを改善できるという点で、プラスになる可能性があります。その一例がRed-GateのSQL Source Controlです。これはSSMSのアドオンであり、SSMSをVisual Team Foundationであるかどうかに関係なく、会社のソース管理システムに接続できます。VS2010にはこのビルトインがありますが、Reg-Gateのツールの価格と比較して、VS2010を購入することなく、たくさんのお金を節約しました。

全体的には好みにかかっていると思います。あなたは快適なものを使って作業します。新しい人を訓練していて、VS2010で訓練する場合、彼らはそれをうまくやっていく方法を知っているため、彼らの好みになります。

SQL Server 2012でのプレイを開始した場合、SSMSがVS2010の構成をゆっくりと確実に獲得していることに気付いているかもしれません。そのため、最終的にはそれらの違いを見分けることができない場合があります。