私は、データ層アプリケーションの機能と、Visual Studio のデータベース エディションでデータベース プロジェクトが何をしたかについて、少ししか知りません。
これら 2 つの異なる重複するデータベースのバージョン管理ソリューションはありますか? それとも、データ層アプリケーション機能は、Visual Studio データベース エディションとデータベース プロジェクトを使用する必要性を完全に置き換えるのでしょうか?
私は、データ層アプリケーションの機能と、Visual Studio のデータベース エディションでデータベース プロジェクトが何をしたかについて、少ししか知りません。
これら 2 つの異なる重複するデータベースのバージョン管理ソリューションはありますか? それとも、データ層アプリケーション機能は、Visual Studio データベース エディションとデータベース プロジェクトを使用する必要性を完全に置き換えるのでしょうか?
DAC は、開発者と DBA 間のインターフェースとして使用できるアプリケーション モデルを提供します。開発者はモデルを編集し、DBA はモデルから管理/デプロイします。たとえば、モデルが構築または抽出されると、複数のサーバーに展開できます。
.dacpac を .exe と想像してください。開発者は .exe を作成し、それを誰かに渡します。この時点で、開発者が .exe がどこで実行されるかを気にする必要がないのは良いことです。なぜなら、.exe は内部的に一貫しており、実行されるか実行されないかのどちらかだからです。開発者が特に 2008、2005、または Azure をターゲットにすることについて心配する必要があるのはなぜですか? アプリモデルを開発するだけで、あとは DAC にお任せください...
このデプロイ アーティファクトを使用すると、いくつかの新しい機能も提供されます。例としては、バージョン管理された展開、最後の展開またはアップグレード以降に誰かがデータベースを変更したかどうかを判断する機能、異なるターゲット サーバーで同じデータベースを作成する機能などがあります。
さまざまなデータベースのアップグレード スクリプトのライブラリを管理する必要がありますか? データベースの状態全体をいつでも構築または取得 (抽出) できると便利だと思いませんか?
VS 2010 のデータベース アプリケーション プロジェクト マッシュアップは、データベース中心の開発者ツールの今後のリリースで解決される予定です。dbschema または DAC に投資しても、上位互換性には影響しません。
現在、データベース プロジェクトとデータ層プロジェクトの違いは、デプロイの時点にあります。dacpac を作成する場合は、データ層プロジェクトを使用します。.dbschema と sql 移行ファイルを作成する場合は、従来のデータベース プロジェクトを使用します。
私の知る限り、データ層アプリケーションは、SQL Azure の展開において将来的に重要になると予想されます。
特に SQL Azure を検討している場合を除き、今のところデータベース プロジェクトを使用します。それはすべて、達成しようとしていることに依存します。SQL ソース管理(私が勤務している Red Gate によるもの) の方がニーズにより適している可能性があります。
VisualStudioデータベースプロジェクトは開発者を対象としていると思います。
データ層アプリケーションはDBAを対象としています。詳細については、このブログを参照してください。