データベース開発に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プレミアムまたはアルティメットをお持ちの場合、.Netツールチェーンに含まれている、やや欠陥のあるデータベース開発ツールが使用されます。 DBプロジェクトをVSソリューションに統合するため、少なくともsprocデプロイメントスクリプトを作成するために使用できます。
ただし、VSにはモデリングツールがないため、PowerDesignerまたはErwinの方が優れています。 Redgateのスキーマ管理ははるかに優れており、SQL Compare Proは非常に安価です（約400ポンドIIRC）。 IMHO SSMSはT-SQL開発に適していますが、VS2010でも確実に実行できます。
VS2010プレミアムは、最高のデータベースモデリングツールほど安価ではありません。また、VS2010 Ultimateは少なくとも同じくらい高価です。 VSプロジェクトとの緊密な統合を犠牲にして、おそらくサードパーティのツールを使用すると、より良い結果が得られます。
代替
少なくとも1つの代替案を提案し、その長所と短所の概要を説明せずに、VS2010をあまり長引かせるべきではないと思います。この目的のために、大規模なプロジェクトを想定します。最近は主にA/P作業を行っていますが、データモデル（およびいくつかの開発作業）を行う100スタッフ年以上のプロジェクトと、主に作業する10スタッフ年の範囲のプロジェクトに関与しています。アナリストまたは開発者として。最近私は最近、データウェアハウスシステムに取り組んでいますが、より大きなプロジェクトは主にアプリケーションでした。さまざまなツールでの私の経験に基づいて、代替ツールチェーンのいくつかの提案を次に示します。
- VS2010 Professional以上。プレミアムまたはアルティメットのプロジェクト管理機能を使用したい場合と使用しない場合があります。
- 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）完全に自動化するようにしてください。
DBパッチのQA。大規模なスキーマでは、特にパッチにデータ移行が含まれる場合、ライブシステムに手動でパッチを適用するプロセスが必要になる場合があります。たとえば、必要に応じて変更のバックアウトをサポートするために、ロールフォワードスクリプトとロールバックスクリプトを用意することが望ましい場合があります。この場合、パッチが実際に正しく機能することをテストする機能が必要になります。リポジトリでデータベーススキーマを管理している場合は、データベースの前にセットアップし、リポジトリから参照データベースを生成することにより、スクリプトをテストできます。 beforeデータベースでパッチスクリプトを実行すると、それがリポジトリモデルと同期するはずです。スキーマ比較ツールを使用してこれをテストできます。
最近、オーダーメイドのアプリケーション開発よりもはるかに多くのデータウェアハウスと統合作業を行ったため、ほとんどの場合、開発チームよりも頻繁にこの問題に遭遇します。しかし、プロジェクト管理ツールと方法論は、外部の利害関係者を管理するという非常に貧弱な仕事をしています。データウェアハウスなどの統合プロジェクトで、プログラム管理に直面して外部依存関係（つまり、制御できないもの）を実際にプッシュするプロジェクト管理ツールを本当に見たいと思っています。重要な統合プロジェクトでは、外部依存関係が無駄な時間の最大の原因です。
この質問は最初に投稿されて以来、この質問への回答をどのように構成するかをいじっています。 VS2010の場合はツールの機能と利点を説明するものではないため、これは困難です。これは、読者にデータベース開発へのアプローチを根本的に変えるよう説得することです。簡単ではありません。
DBA、開発者/ dba、およびOLTPとデータウェアハウジングの両方にまたがるバックグラウンドミックスで、熟練したデータベースプロフェッショナルからのこの質問への回答があります。データベースのすべての面でこれに取り組むのは現実的ではありません。開発を一挙に行うので、特定のシナリオについてケースを作ってみます。
プロジェクトがこれらの基準に当てはまる場合、VS2010には説得力のある事例があると思います。
- あなたのチームは、アプリケーション開発にVS2010を使用しています。
- チームはソース管理とビルド管理にTFSを使用しています。
- データベースはSQL Serverです。
- あなたのチームはVS自動テストをすでに持っているか、興味があります。
データベース開発のためにVS2010を評価している場合、聖書は Visual Studio ALM Rangers から Visual Studio Database Guide になります。参照のない引用符は、このドキュメントから引用されます。
じゃあね...
データベース開発プロセスがアプリケーション開発と異なるのはなぜですか？
データ。その厄介なデータがなければ、データベース開発は容易ではありません。すべてのリリースですべてを削除し、この面倒な変更管理を忘れることができます。
データが存在すると、データベースの変更プロセスが複雑になります。これは、データベースのテーブルや他のデータスキーマの形状に影響を与えるアプリケーション開発の取り組みによって変更が導入されると、データが移行、変換、または再ロードされることが多いためです。この変更プロセス全体を通じて、生産品質データと運用状態は、整合性、価値、および組織への有用性を脅かす可能性のある変更から保護する必要があります。
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)
4週間の5年間のスプリントは、いくつかの面白いバージョンのスクリプトになり、展開時間への影響を最小限に抑えるために追加の人手が必要になります。
それでは、SSMSに何か問題がありますか？いいえ、SQL Serverの管理には、何が適しているのかがわかります。それが行うふりをしないことは、変更を管理する（時には）非常に複雑なタスクでデータベース開発者を支援することです。
ソースからデータベースのすべてのバージョンを構築して将来のバージョンにアップグレードできない場合、ソース管理が壊れています。そう思わない場合は Eric Sinkに尋ねてください 。
SSMS + <-スキーマ比較ツールを挿入->はどうですか？
これは間違いなく正しい方向への一歩であり、スクリプトの保守に必要な手作業の多くを取り除きます。しかし（それは大きいですが）、通常、手動の手順が含まれます。
一般的なスキーマ比較ツールは完全に自動化でき、ビルドプロセスに統合できます。ただし、私の経験では、比較を手動で実行し、結果のスクリプトを目で確認してソース管理にチェックインし、手動で実行して展開するという方法が一般的です。良くない。
信頼できる人間がビルドまたはデプロイメントのプロセスに関与しなければならないときはいつでも、リスクを導入し、プロセスを反復不可能にします。
あなたとあなたのチームが完全に自動化されたスキーマの比較と展開を行っている数少ない人の中にいるなら、あなたには嫌いです！皆さんは、VS2010が次のようなメリットを提供することに最もオープンである可能性が高いです。
- 手動による手順は危険であることをすでに承諾しています。
- 自動化の価値がわかります。
- あなたはそれを機能させるために必要な時間を費やす用意があります。
1つのステップでビルドを作成できない、または1つのステップでデプロイできない場合、開発とデプロイメントのプロセスは失敗します。そう思わない場合は Joel Spolskyに質問してください 。
なぜVS2010？
@NickChammasが提起した質問は、VS2010がデータベース開発のゲームチェンジャーである理由を示すキラー機能を探すことです。私はその根拠に基づいて主張することはできないと思います。
おそらくコミカルで、他の人がこのツールの欠陥を見ると、私は採用の大きな理由を見つけます：
- あなたのアプローチを変更する必要があります。
- あなたとあなたのチームは異なる方法で働くことを余儀なくされます。
- すべての変更の影響を詳細に評価する必要があります。
- すべての変更を行うようにガイドされます べき等 。
あなたがプロジェクトの唯一のDBAであり、データベースへのすべての変更を管理している場合、この推論は馬鹿げたことにばかげているように思われるはずです。ただし、@ BrentOzarにポイントがあり、新しいルールの1つが Everybody's the DBA であると思われる場合、チームのすべての開発者が作業できるようにデータベースの変更を制御する必要があります。
データベースプロジェクトの採用には、開発者によっては精神的な変化（古い習慣を破るのが難しい）か、少なくともプロセスまたはワークフローの変更が必要になる場合があります。プロダクションデータベースがデータベースの現在のバージョンを表すデータベースアプリケーションを開発した開発者は、ソースコードベースのアプローチを採用する必要があります。このアプローチでは、ソースコードがデータベースに変更を加える手段になります。 Visual Studioデータベースプロジェクトでは、プロジェクトとソースコードはデータベーススキーマの「1つのバージョンの真実」であり、アプリケーションスタックの他の部分で開発者または組織が既に使用している可能性が高いSCMワークフローを使用して管理されます。データについては、本番データベースは本来の「1つのバージョンの真実」のままです。
データベース開発へのVS2010アプローチの採用に成功するために必要な根本的な変化に到達しました…
データベースをコードとして扱う
ライブデータベースを変更する必要はありません。すべてのデータベースの変更は、アプリケーションの変更と同じパターンに従います。ソースの変更、ビルド、デプロイ。これはMicrosoftからの一時的な方向転換ではありません これはSQL Serverの未来です 。 データベースとしてのコード はここにあります。
データベース開発者は、アプリケーションのバージョンのオブジェクトの形状を定義します。データベースエンジン内の既存のオブジェクトを目的の形状に変更する方法ではありません。あなたは自分自身に疑問を抱くかもしれません：これは、customerテーブルがすでに含まれているデータベースに対してどのようにデプロイされますか？ここで、デプロイメントエンジンが活躍します。前述のように、デプロイメントエンジンはコンパイルされたバージョンのスキーマを取得して、データベースデプロイメントターゲットと比較します。差分エンジンは、プロジェクトからデプロイするバージョンと一致するようにターゲットスキーマを更新するために必要なスクリプトを生成します。
はい、同様のパターンに従う他のツールがあり、私の回答に課した制約の範囲外のプロジェクトについては、同等に検討する価値があります。しかし、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に慣れれば、次世代のデータベース開発ツールの準備が整います。
SSMSを知らない場合やサードパーティのツールを使用した場合は、VSが適切に表示される場合があります。 Red Gateツールをスキーマ比較などに使用すると、VSのギャップが目立ちます。また、無料のSSMSプラグインも使用できます。
ソース管理ビットは誤解を招くものです。本番データベースには参照コピーがあります。開発者が使用しているものではありません。見る
私はVisual StudioをSSRSレポートデザインとSSISパッケージに幅広く（よく、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スキーマです。データベースを更新するために必要なコマンドのみを実行します。データベースで nit test を作成することもできます。データベースプロジェクトに関する他の優れた記事が利用可能です here 。デプロイ機能を使用すると、プレスクリプトとポストスクリプトを使用できます。これらのスクリプトを使用すると、検証を行ったり、システムテーブルにデータを挿入したりできます。
ここ は、データベースプロジェクトに適したステップバイステップの手順です。
SQL ServerをインストールするときにVS2010があるため、VS2010よりもSSMSを使用しています。これはおそらく、SSMSがVS2010、IMHOよりも多く使用されている最も重要なことです。
また、Red-Gateのようなベンダーが、必ずしもVS2010ではなく、SSMSと統合するツールを公開していることもわかりました。これは、Microsoftが提供していないSSMSを改善できるという点で前向きです。これの1つの例は、Red-GateのSQLソース管理です。これは、SSMSへのアドオンであり、SSMSを会社のソース管理システムに接続できます。 VS2010にはこの機能が組み込まれていますが、Reg-Gateのツールの価格と比較すると、VS2010を購入する必要なく、かなりのお金を節約できました。
全体的には好みによると思います。あなたは快適なもので働きます。新しい人をトレーニングしていて、VS2010で彼らをトレーニングする場合、彼らはそれを乗り越える方法を知っているので、それが彼らの好みになるでしょう。
SQL Server 2012を試してみると、SSMSがゆっくりと確実にVS2010の構成を取得していることに気づいたかもしれません。したがって、最終的にはそれらの違いを見分けることができない場合があります。