Microsoft SQL Serverデータツール

この記事では、MS SQL Serverに基づいたデータベースの開発を大幅に促進できるVisual Studioの便利な追加機能について説明したいと思います。
SSDTを使用する主な利点は次のとおりです。

• データベーススキーマを単純に変更（リファクタリング）する機能（テーブル列の名前を変更でき、それを参照するすべてのビュー、関数、ストアドプロシージャは、変更を反映するように自動的に修正されます）
• データベースの単体テストを作成する
• ソース管理にデータベース構造を保存する
• 回路/データと、回路/データを目的の状態にするスクリプトを生成する機能との比較

もちろん、SSDTを使用する利点はこれで終わりではありませんが、残りは上記のものほど印象的ではありません。 これらの利点を活用する方法に興味がある場合は、猫の下でお願いします。

インストールと最初の知人

インストールする必要があるものはすべて、データデベロッパーセンターのダウンロードページにあります 。 必要なバージョンを選択したら、コンピューターにツールを簡単にインストールして説明できます。理由はわかりません。 インストール後、新しいプロジェクトを作成するためのウィンドウに新しいタイプのプロジェクトが表示されます。


新しいプロジェクトを作成すると、次のように表示されます。


SQL Serverオブジェクトエクスプローラーパネル（[表示]メニュー-> [SQL Serverオブジェクトエクスプローラー]）には、SQL Server Management Studioのオブジェクトエクスプローラーと非常によく似たものがあります。データベース開発段階であまり意味のないものはすべて削除されています。
既存のデータベースに接続することにより、いわゆる接続モードでデータベースを開発できます。 これは、SQL Server Management Studioで使用されている従来のアプローチと大差ないため、この記事では考慮しません。

切断モード

この開発モードは、私たちにとって最も興味深いものです。 SSDTを使用する主な利点を提供するのは彼です。
作業の基本は非常にシンプルなアイデアです-開発者がデータベースオブジェクト（テーブル、ビュー、ストアプロシージャなど）を作成するためのすべてのスクリプトを、既存または新しいソリューション（ソリューション）の一部として特別なタイプのプロジェクトに保存できるようにします。 スクリプトに基づいて、Visual StudioはDACPACファイルを生成できます。これは、基本的にすべてのt-sqlスクリプトを含むzipアーカイブです。 DACPACファイルがある場合、DACPACで説明されているスキーマとターゲットデータベースのスキーマを比較することにより、必要なデータベースインスタンスで公開することができます。 公開中に特別なメカニズムが比較を行い、その結果、データを失うことなく変更を適用するための移行スクリプトが自動的に作成されます。
これを実際に見るために、次の例を見ることを提案します。
インポート機能から始めましょう。 プロジェクトのコンテキストメニューを呼び出して、3つの可能なオプションを確認します。

• スクリプト（* .sql） -特定の場所から1つ以上の* .sqlファイルをプロジェクト構造に追加します。
• データ層アプリケーション（* .dacpac） -* .sqlファイル、および上記の特別なDACPACファイルからのさまざまなデータベース設定を追加します。 データベーススキームだけでなく、データとさまざまなデータベース設定を含めることができます。
• データベース...-前のオプションに似ていますが、既存のデータベースがデータソースとして機能します

「データベース...」オプションを選択し、ローカルデータベースをインポートします。 1つのテーブルと1つのストアドプロシージャが含まれています。 SQL Serverオブジェクトエクスプローラーのソースデータベースは次のとおりです。

インポートが完了すると、データベース構造がソリューションエクスプローラーで* .sqlファイルとして表示されるという違いを除いて、非常によく似た図が表示されます。

また、すべての可能なデータベースオブジェクトをリストする[新しいアイテムの追加]ダイアログボックスを使用して、いつでも新しいアイテムを追加できます。

TestTableというテーブルを追加します。 新しいTestTable.sqlスクリプトファイルがプロジェクトのルートに追加され、便宜上、Tablesフォルダーに転送します。

テーブルスキーマを作成するには、デザイナーパネルとT-SQLパネルの両方を使用できます。 あるパネルで行われたすべての変更は、すぐに別のパネルに表示されます。
既存のスクリプトを変更することもできます。 このためのVisual Studioは、便利で愛されているIntelliSenseを提供します。 物理データベースに接続していないため、Visual Studioはプロジェクト内のすべてのスクリプトを解析してIntelliSenceが正しく動作するようにし、データベーススキーマに加えられた最新の変更を即座に反映できるようにします。

私たちは、ベースの漸進的な変化を心配する必要がないという事実に注意を喚起したいと思います。 代わりに、オブジェクトが再作成されているかのように常にスクリプトを作成します。 DACPACパッケージが公開されると、DACPACファイルとターゲットデータベースのスキーマを比較することにより、移行スクリプトが自動的に生成されます。
既に述べたように、DACPACには図とデータだけでなく、プロジェクトのプロパティウィンドウを使用して表示/編集するための多くの便利な設定も含まれています。

[ターゲットプラットフォーム]プロパティを使用すると、プロジェクト内のスクリプトが検証されるデータベースのバージョンを設定できます。 サポートされているMS SQL Server 2005の最小バージョン。たとえば、データベースバージョン2005を設定し、Geography型の列を作成しようとすると、コンパイル中に次のメッセージが表示されます。

[プロジェクト設定]タブで、[データベース設定]ボタンをクリックしてデータベース設定を設定できます。 クリックすると、SQL Server Management Studioでの表示に使用される設定に類似した設定のダイアログが表示されます。

また、スクリプトでさらに使用するためにさまざまな変数を設定できる[SQLCMD Variables]タブについても言及したいと思います。

DACPACファイルの公開（公開）

すべての設定が設定され、* .sqlスクリプトが追加/更新されたら、ターゲットデータベースに変更を適用できます。 これを行うには、[ビルド]-> [公開]メニューに移動するか、プロジェクトのコンテキストメニューで同様のアイテムを選択します。

表示されるダイアログボックスで、接続文字列をターゲットデータベース（ターゲットデータベース）に設定し、必要に応じて、[詳細設定]ボタンをクリックして追加設定を行います。

ほとんどの設定は追加の説明がなくても理解できるため、詳細に説明することはしませんが、プロジェクトを正常に「アップロード」できない場合に問題を把握できるように、設定に精通することをお勧めします。

ターゲットデータベースに複数回公開する場合は、[プロファイルの作成]ボタンをクリックして、設定を公開プロファイルに保存できます。 これにより、拡張子が* .publish.xmlのファイルがプロジェクトに追加され、将来、設定を再入力せずに公開できるようになります。 パブリケーションプロファイルのいずれかをデフォルトで使用する必要がある場合は、パブリケーションファイルのコンテキストメニューで[デフォルトのパブリッシュプロファイルとして設定]を選択できます。 このプロファイルは、[公開]ダイアログに自動的にロードされます。

[公開]ボタンをクリックすると、必要なすべての変更をすぐに適用できます。 また、適切な移行スクリプト（[スクリプトを生成]ボタン）を生成することで、後で延期できます。移行先データベースを目的の状態にするために必要なすべての指示が含まれます。
データベースにアクセスできない場合は、プロジェクトのコンパイルによって作成され、.. / bin / Debug / Database1.dacpacにあるDACPACファイルの形式で作業の結果を転送できます。 たとえば、ファイルをデータベース管理者に渡すと、彼はターゲットデータベースに変更を適用するための便利な方法を使用できるようになります。
DACPACを公開する方法（公開）：

• SSDTがインストールされたVisual Studioの無料版（特に、SSDTと共にインストールされたDACフレームワークの一部であるクライアントツールは、公開に使用されます）
• MS SQL Server Management Studio + DACフレームワーク
• コンソールユーティリティSqlPackage.exe
• Windows PowerShell（ 例 ）
• データ層アプリケーションフレームワーク（DACFx）を使用すると、C＃プログラムからメソッドを呼び出してDACPACファイルを配置できます（ ドキュメントと例 ）

データシード

プロジェクトでは、DataSeedingフォルダーを作成し（名前は関係ありません）、新しいスクリプトを追加します。

実際、ユーザースクリプトセクションのすべてのタイプは通常の* .sqlスクリプトであり、新しく作成されたファイルの「ビルドアクション」プロパティの値のみが異なります。

PostDeployment.sqlファイルのロジックは、データベーススキーマにすべての変更を適用した後に実行されます。 PreDeployment.sqlが作成された場合、スキーマの変更を適用する前にロジックが実行されます。
スクリプト（ビルドではない）テンプレートで作成されたファイルのビルドアクションプロパティの値は、「なし」に設定されます。 これらは、展開前または展開後のスクリプトから呼び出される個別のファイルでコマンドを簡単に構造化するのに役立ちます。
スクリプトテンプレートを使用して作成されたファイルのビルドアクション値は「ビルド」に等しく、その内容は結果のスクリプトに追加されます。これは、データベーススキーマの変更時にDACPACファイルが発行されると実行されます。
プロジェクトに配置できるPost Deploymentスクリプトは1つだけであり、そのサイズは急速に大きくなる可能性があるため、データ挿入ロジックを個別のスクリプトに配置することをお勧めします。 そのため、スクリプト（ビルドではない）タイプのファイルを追加し、ポストデプロイメントスクリプトにそのファイルへのリンクを追加します。 これがどのように見えるかです：



これで、プロジェクトを公開するときに、Employeesテーブルの2つのレコードが常にデータベースに挿入されます。

ツール-> SQL Server

データベースプロジェクトを作成する機能に加えて、SSDTをインストールすると、[ツール]メニューから使用できる多数の便利なツールが追加されます。

名前から、各ポイントが何をするのかが明確だと思います。 例として、回路を比較するための便利なグラフィックツールを示します。 ソースおよびターゲットとして3つのオプションのいずれかを選択できます。

プロジェクトをローカルデータベースと比較します。 比較の結果は次のようになります。

結果のウィンドウで、さまざまなグループ化方法（スキーム、オブジェクトの種類、必要なアクション）を適用して、提案された変更をより便利に表示し、更新が必要なオブジェクトを選択できます。 移行スクリプトを適用するには、[更新]ボタンをクリックする必要があります。これにより、ターゲットDBがプロジェクトの状態になります。

リファクタリング

これは私のお気に入りの機能です。 例として、EmployeesテーブルのLastName列の名前を変更する方法を示します。 これを行うには、テーブル作成スクリプトを開き、テーブルエディターで[LastName]列を選択し、[SQL]-> [リファクタリング]メニューで[名前の変更]アイテムを選択します。


新しい名前を設定します。


名前変更の結果を確認し、提案された変更を適用します。


その結果、すべてのスクリプトが変更され、最初のリファクタリング後に特別な* .refactoringファイルがプロジェクトに追加されます。 スキーマへのすべての変更をXMLドキュメント形式で履歴順に保存します。 このデータは、移行スクリプトの生成に役立ち、スキーマとデータのより正確な移行を可能にします。

単体テスト

最初の単体テストを作成しましょう。 これを行うには、テストするストアドプロシージャのコンテキストメニューを呼び出します。

表示されるダイアログで、追加オブジェクト（存在する場合）を選択し、テストプロジェクトのタイプと名前、および単体テストコードを含むクラスの名前を設定することができます。


プロジェクトを作成したら、テストを実行するデータベースといくつかのプロジェクト設定を選択するように求められます。


正常に作成されたら、ユニットテストのグラフィカルエディターを開き、下部にテストオブジェクトのさまざまなチェックが表示されます。 私たちの場合、これはストアドプロシージャEmployeeGetListです。

私たちのタスクは、必要なSqlスクリプトを記述し、スクリプトコードの実行後に生成される必要な検証条件を設定することです。 チェックは異なる場合があります：ランタイム、返される行の数、返されるデータのチェックサムなど。 チェックの完全なリストは、スクリプトテキストの下のドロップダウンメニューとチェックテーブルの上にあります。 テストごとに、標準の[プロパティ]パネルからいくつかの設定を設定できます。 呼び出すには、特定のチェックのコンテキストメニューで[プロパティ]項目を選択する必要があります。
たとえば、返される行数のチェックは次のようになります。


したがって、チェックサムを確認できます。

実際、このチェックはスクリプトによって実行され（Employeesテーブルから2行を取得）、受信したデータのチェックサムを見つけます。 テストを作成する段階でのタスクは、参照データを見つけ、それらのチェックサムを計算することです。将来、結果はこの値で検証されます。 つまり、これは、ストアドプロシージャの結果が変わらないことを確認する便利な方法です。 チェックサムコントロール値を取得するには、プロパティウィンドウのボタンを使用する必要があります。これにより、参照ベースを選択し、Chexum参照値を取得できます。

おわりに

この簡単な概要により、SSDTの概要と、プロジェクトでSSDTがどのように役立つかについての一般的なアイデアを得ることができたと思います。 もちろん、すべての詳細はここでは考慮されていません。 しかし、開発者として、あなたはこれを必要としません。 機能のリストについての一般的な考えを持っている必要があり、それらのさらなる使用が直感的になることを望みます。 SSDT開発者は一生懸命働き、ツールに多数のヘルパー（ウィザード）とコンテキストヒントを提供しました。