Share via

大規模なデータベースのチーム開発の開始

  • [アーティクル]

Visual Studio を使用してデータベース スキーマへの変更を管理するには、まずデータベース プロジェクト、サーバー プロジェクト、またはデータ層アプリケーション プロジェクトを作成し、次に、管理対象のデータベースからオブジェクトと設定をインポートします。 非常に大規模なデータベースの変更を管理する場合は、オブジェクトをいくつかのデータベース プロジェクトに分割することもできます。 この方法により、データベースのさまざまなセクションで、どのチームまたは開発者がコードを追加、変更、または削除できるようにするかを制御できます。

データベースを分割するには、次の 2 つの方法があります。

  • 複合プロジェクト — データベース プロジェクト参照でリンクされた 2 つ以上のデータベース プロジェクト (同じソリューション内のデータベース オブジェクト。またはコンパイルされた .dbschema ファイルを参照できます) にデータベースのセクションを定義できます。 参照を含むプロジェクトを配置するときに、参照先のプロジェクトもすべて配置します。 複合プロジェクトにプロジェクト間の循環参照を含めることはできません。

  • 部分プロジェクト — データベース プロジェクトのセクションを .files ファイル形式でエクスポートできます。 次に、別のデータベース プロジェクトを作成し、それに部分プロジェクト (.files ファイル) を含めます。 次に、元のファイルの書き込みアクセス許可を設定して、それらのファイルの変更を制限します。 そのため、2 つ目のプロジェクトで作業を行う開発者は、その読み取り専用オブジェクトを参照する追加のオブジェクトを作成できますが、変更はできません。 2 つ目のプロジェクトをビルドおよび配置すると、読み取り専用のセクションを含めて、データベースの完全なコピーがビルドされます。 部分プロジェクトには循環参照を含めることができます。

後で詳しく説明するように、どちらの方法にも制限があります。

データベース プロジェクトの種類の指定

データベース プロジェクトを作成するときは、使用している SQL Server のバージョンに対応するプロジェクトの種類を指定します。 たとえば、管理するデータベースが SQL Server 2005 に基づく場合は、[SQL Server 2005 データベース プロジェクト] または [SQL Server 2005 ウィザード] を指定します。 ウィザードを使用すると、プロジェクトの作成だけでなく、一部のビルドや配置の設定の構成、およびデータベース オブジェクトと設定のインポートを同時に行うことができます。

データベース オブジェクトと設定のインポート

プロジェクトを作成したら、データベースのインスタンスまたはスクリプトから、オブジェクトと設定をインポートできます。 スクリプトからデータベースをインポートするときには、そのオブジェクト定義が検証され、解析できないステートメントは ScriptsIgnoredOnImport.sql ファイルに格納されます。 既に存在しないオブジェクトを参照するオブジェクト定義をインポートした場合は、プロジェクトをビルドおよび配置する前に、そのエラーを解決しておく必要があります。 たとえば、既に存在しないテーブルを参照するストアド プロシージャをインポートした場合などです。 エラーを解決するには、そのストアド プロシージャを削除します。

大規模なスキーマをインポートする場合は、そのようなエラーの解決に時間がかかることがあります。 ただし、チーム メンバーが Visual Studio Premium でスキーマを更新するときに、気付かないうちにこのようなエラーを追加する可能性はありません。 チーム メンバーがオブジェクト定義を変更して保存する際には、変更がすべて検証されます。そのため、チーム メンバーはエラーを直ちに修正し、ライブ データベースにこのようなエラーが配置されるのを防ぐことができます。 オブジェクト定義の警告を解決したら、データベース コードを分析して設計、名前付け、およびパフォーマンスの問題を検出することも検討する必要があります。 詳細については、「データベース コードの分析によるコードの品質の向上」を参照してください。

一般的なタスク

一般的なタスク

関連する参照先

データベース プロジェクト、および部分プロジェクトと複合プロジェクトの制限の詳細を理解する: データベース プロジェクトを使用してスキーマの変更を管理する方法の基本的な概念を習得できます。

実習を行う: 機能紹介のチュートリアルを実施することで、部分プロジェクトまたは複合プロジェクトを使用してデータベース プロジェクトを分割する方法を理解できます。

既存のデータベース スキーマをバージョン コントロールする: データベース プロジェクト ウィザードを使用すると、プロジェクトの作成、プロジェクトの設定の構成、およびスキーマのインポートを実行できます。 後でスキーマをインポートする場合や、スキーマのインポート元のデータベースにアクセスするためのアクセス許可がない場合は、空のプロジェクトを作成することもできます。 スキーマをインポートした後で、プロジェクトをバージョン コントロールに追加できます。

データベース プロジェクトを分割してオブジェクト定義を共有する: 1 つのデータベース プロジェクトからオブジェクト定義をエクスポートして、別のプロジェクトで再利用できます。 部分プロジェクトの定義をインポートした先のプロジェクトにアクセスできるチーム メンバーであっても、インポートされたオブジェクトの変更はできません。 これにより、データベース コードのサブセットに対する変更を管理できます。

参照を追加して複合プロジェクトを作成する: データベース プロジェクトへの参照を追加して、複合プロジェクトを作成します。ただし、サーバー変数およびデータベース変数の値は指定しません。 プロジェクトを配置するときに、参照先のプロジェクトもすべて配置します。

部分プロジェクトの使用と制限

次の図は、部分プロジェクトを使用する標準的なシナリオを示しています。

Database Edition での部分プロジェクトの使用

Database Edition の部分プロジェクト

この例では、プロジェクトに 2 つのオブジェクト セットが含まれています。 別の開発者またはチームがこのプロジェクトにストアド プロシージャを追加できるようにしますが、開発者やチームが他のオブジェクトを誤って変更しないようにする必要があります。 部分プロジェクトを使用してこの目標を達成するには、次の手順を実行する必要があります。

  1. オブジェクトのグループを、スキーマまたはオブジェクトの種類別に A.files と B.files にエクスポートします。

  2. 他の開発者またはチームがストアド プロシージャ (sproc とも呼ばれます) を作成するための別のデータベース プロジェクトを作成します。

  3. 作成したデータベース プロジェクトに、エクスポートした部分プロジェクト (A.files および B.files) をインポートします。

  4. インポートされた部分プロジェクト内のオブジェクトに対するソース コード管理アクセス許可を、読み取り専用アクセスのみが許可されるように制限します。

この時点で、他の開発者またはチームは、オブジェクトを追加し、プロジェクトをビルドおよび配置して、変更をテストすることができます。

データベースに長い名前のオブジェクトが含まれている場合や、データベース プロジェクトを作成したパスが長い場合、部分プロジェクト (.files ファイル) を別のデータベース プロジェクトにインポートできないことがあります。 次の推奨事項に従うことにより、このような問題を回避できます。

  • できるだけ短いパス名のフォルダーにデータベース プロジェクトを作成します。 たとえば、"C:\Documents and Settings\UserName\My Documents\Visual Studio 2008\Projects" よりも "D:\MyProjects" の方が適しています。

  • データベース オブジェクトを非常に長い名前にすることは避けます。 外部キーは、長い名前を持つオブジェクトの典型的な例です。 外部キーの名前が "FK_ReferencingTable_ReferencedTable_ReferencedColumn1_ReferencedColumn2" である場合、そのキーの定義を含む部分プロジェクトをインポートしようとするとエラーが発生することがあります。

複合プロジェクトの使用と制限

次の図は、複合プロジェクトを使用する標準的なシナリオを示しています。

Database Edition での複合プロジェクトの使用

Database Edition の複合プロジェクト

この例では、スキーマの定義を含むデータベース プロジェクトを作成します。 次に、テーブルとビューの定義を含む別のデータベース プロジェクトを作成し、さらに、ストアド プロシージャの定義を含むもう 1 つのデータベース プロジェクトを作成します。 3 つ目のプロジェクト (データベース プロジェクト C) には、他の 2 つのデータベース プロジェクトへの参照が含まれています。 3 つ目のプロジェクトをビルドおよび配置すると、他のプロジェクトも自動的に配置されます。

複合プロジェクトを使用する場合は、各プロジェクトを個別にビルドおよび配置できる必要があります。 複合プロジェクトにプロジェクト間の循環依存関係を含めることはできません。 複合プロジェクトを使用すると、データベースをオブジェクトの種類別に分割できます。 たとえば、スキーマを 1 つのプロジェクトに、テーブルとビューを別のプロジェクトに、ストアド プロシージャをさらに別のプロジェクトにそれぞれ含めることができます。

関連するシナリオ

  • データベースのチーム開発の開始
    データベース プロジェクトでデータベース スキーマのオフライン形式を作成し、そのプロジェクトをバージョン コントロールに追加する方法について説明します。

  • 他のデータベースを参照するデータベースのチーム開発の開始
    データベース スキーマのオフライン形式を作成し、他のデータベースへの 1 つ以上の参照を定義し、対象となる配置環境用に変数の値を定義し、プロジェクトをバージョン コントロールに追加する方法について説明します。

  • SQLCLR オブジェクトを参照するデータベースのチーム開発の開始
    データベース スキーマのオフライン形式を作成し、SQL 共通言語ランタイム (CLR: Common Language Runtime) オブジェクトを含むアセンブリへの参照を定義し、それらの SQLCLR オブジェクトを参照するデータベース オブジェクトを定義して、プロジェクトをバージョン コントロールに追加する方法について説明します。

  • XML スキーマ コレクションを使用するデータベースのチーム開発の開始
    データベース スキーマのオフライン形式を作成し、XSD ファイルへの参照を定義し、そのファイルを使用する XML スキーマ コレクションを定義し、その XML スキーマ コレクションを使用する列を定義して、プロジェクトをバージョン コントロールに追加する方法について説明します。

  • 共有サーバー オブジェクトを参照するデータベースのチーム開発の開始
    データベース スキーマのオフライン形式を作成し、共有サーバー プロジェクトへの参照を定義し、サーバー プロジェクトで定義されているオブジェクトへの参照を追加して、データベース プロジェクトをバージョン コントロールに追加する方法について説明します。