データ層のアプリケーションプロジェクトは、Visual Studio Database Editionのデータベースプロジェクトに取って代わりますか？

Question

データ層アプリケーションの機能と、Visual Studioのデータベースエディションでデータベースプロジェクトが行ったことに少しだけ精通しています。

データベースバージョン制御用のこれら2つの異なる重複ソリューションはありますか？または、データ層のアプリケーション機能は、Visual Studio Database Editionおよびデータベースプロジェクトを使用する必要性を完全に置き換えますか？

Answer 1

現在、データベースプロジェクトとデータ層プロジェクトの違いは、展開の時点にあります。 DACPACを作成する場合は、データティアプロジェクトを使用します。 .dbschemaおよびSQL Migrationファイルを作成する場合は、従来のデータベースプロジェクトを使用します。

私が知る限り、SQL Azureの展開では、データ層アプリケーションが将来重要になると予想されます。

SQL Azureを具体的に見ていない限り、今のところデータベースプロジェクトを使用します。それはすべて、あなたが達成しようとしていることに依存します。それはそうかもしれません SQLソースコントロール （Red Gate、私が働いている会社）は、あなたのニーズにより適しています。

Answer 2

DACは、開発者とDBAの間のインターフェイスとして使用できるアプリケーションモデルを提供します。開発者はモデルを編集し、DBAはモデルから管理/展開します。たとえば、モデルが構築または抽出されると、複数のサーバーに展開できます。

.dacpacを.exeとして想像してください。開発者は.exeを構築し、それを誰かに渡します。この時点で、開発者が.exeが内部的に一貫しているため、その.exeがどこで実行されるかを心配する必要がない場合、それは素晴らしいことです。開発者は、2008年、2005年、またはAzureを具体的にターゲットにすることを心配する必要があるのはなぜですか？アプリモデルを開発するだけで、DACに残りの世話をさせます...

この展開アーティファクトを使用すると、いくつかの新しい機能も提供されます。例には、バージョン付きの展開、最後の展開またはアップグレード以降に誰かがデータベースを変更したかどうかを判断する機能、異なるターゲットサーバーで同じデータベースを作成する機能が含まれます。

さまざまなデータベースのアップグレードスクリプトのライブラリを管理する必要がありますか？データベースの状態全体を任意の時点で構築またはキャプチャ（抽出）できたらいいのではないでしょうか？

2010年VSのデータベースアプリケーションプロジェクトMashupは、データベース中心の開発者ツールの今後のリリースで解決されます。 DBSchemaまたはDACへの投資は、前方の互換性に影響しません。

Answer 3

Visual Studioデータベースプロジェクトは開発者を対象としていると思います。

データ層アプリケーションはDBAを対象としています。見る このブログ 詳細については。