私は最近、それを試してみました（SQL 2008版）と私は彼らがかなり大丈夫だと思います。唯一の問題は、ウィザードがすべてのデータを最初に消去することなく、データベース構造を更新するのに十分なインテリジェントではないということです。これらのプロジェクトは実際には使われていないのですか？Visual Studioで "データベースプロジェクト"を使用している人はいますか？
実際には、それらを使用している人や、まったく言及していない人は見られません。あなたが明示的にそれを探すのでなければ、ブログやフォーラムには何も表示されません。
どうしたのですか？
Visual Studio Database Editionの一部であるデータベースプロジェクトを使用します。これは素晴らしいツールです。基本的には、スキーマ全体を定義してスクリプトを作成し、ソース管理にチェックインします。その後、差分スクリプトを生成するためのツールが組み込まれていますが、それはデータを削除しません。
これはデータ比較ツールも備えているので、データベース間のデータを比較してスクリプトを生成してデータベースを同じものにすることができます。
最近のGDRリリースには、いくつかの面白い機能が追加されています。このように、組み込みのデプロイメント・メソッドを使用すると、デプロイメント・パッケージを生成することができます。デプロイメント・パッケージを実行すると、ターゲット・データベースが分析され、差分のみが適用されます。
Team Studio - Team Suiteまたは開発版をお持ちの場合は、Database Editionを使用できます。
データベース開発の大きな進化です。
私たちはそれらを使用しています。私たちはすべてのスキーマの作成/更新スクリプトとストアドプロシージャを保持しています。主な目的は、プロジェクトをSourceSafeまたはSVNに接続できることです。
SQLスクリプトのバージョン管理を維持する簡単な方法です。
VSでいくつかのSQLテストをしようとするとちょっと風変わりですが、その周りに方法があります。
更新私たちは、実際にそれが私たちの配置スクリプト、私たちのデプロイツールに組み込まれてい
、（フラグ付きのフォルダーを除く）DBプロジェクトを通過し、すべてのスクリプトを実行します。プロジェクトを実行するための簡単なツールを作成しました。 DBプロジェクトを展開するための他のソリューションを誰かが持っていれば助かります。
Glennularのように、私たちはバージョンを使用してスキーマとs'procsを制御しています。
私たちはかなり高度なバージョン管理構造（CI、デベロッパーへの自動デプロイメント、ワンクリックでステージングしてプロードする展開）を持っていますが、私たちはその構造内のDBプロジェクトを一切含んでいません。我々はまだそれを信用していない。
UPDATE：は
（空間でのアウトの）私たちは、会社の機能領域（セールス、マーケティング、など）のための別のTFSのプロジェクトを持っています。各TFSプロジェクト内には、メインフォルダとプロダクションフォルダがあります。また、データベースプロジェクトを含む1つのTFSプロジェクトと、共通アセンブリ/ビジュアルスタジオプロジェクトを含むもう1つのプロジェクトもあります。
リリース時に、メインからプロダクションに分岐します。我々はそれに対処するにはあまりにも速く動くので、私たちはステージングブランチを持っていません。間違いなく、私たちの生産性は、私たちが1週間に行う生産レベルのリリースの数によって測定されます。バグ修正、新機能など
CIはすべてのチェックインによってビルドサーバーがDEV環境に展開されるようにメインブランチに設定されています。ユニットテストとWebテストが実行され、正常に完了した場合、ビルド品質は自動的に「開発」に設定されます。ビルド品質を「ステージング中」に変更すると、以前の「ステージング中の」ビルドが「拒否」に設定され、そのビルドがステージングサーバーにプッシュされ、構成ファイルが正しいサーバーを指すように更新されます。 （私はこれにTFS DeployerとPowerShellスクリプトを使用しました）。
QAはステージングサーバーからテストします。幸せになると、プロダクションチームはビルドクオリティを「プロダクション」に変更します。これによりビルドがプロダクションエリアに送られ、手動で正しい場所にコピーされます。プロダクションが完了すると、プロダクションは開発者にそのバージョンをプロダクションフォルダに分岐します。 QAはまた、実際にすべてが期待どおりに機能していることを確認するために、生産テストのバッテリーを誰に通知しますか。
プロダクションリリースの間にどのような変更が存在するかを示すレポートが設定されているため、導入されているすべてのチェックインがわかっています。これにより、データベースの変更やその他の潜在的に破損しているコードなど、未知のデータがポップアップするのを防ぐことができます。
さらに、私たちのBAはTeam System Web Accessを介して作業項目を追跡しており、これらの項目がいつ生産されているかを知っています。
私たちのDBAはデータベース版（GDR）を使用していますが、自動配備の制御レベルには感心していません。私は、Rosarioが製品ラインへのより良い展開制御をもたらすことを期待しています。それまではTFS Deployerとpowershellがあります。
バージョン管理構造を少し拡張できますか？ –
データベースプロジェクトを使用して、SQLスクリプトのバージョン管理を提供します。 Visual Studio環境を使用してSQLを編集することも好きです。クエリアナライザよりも新しい開発者の方には少し使いやすくなっています。
私はそれらをいくつかの有料プロジェクトで使用しました。私はその素晴らしいツールだと思います。 Thatsは言った、私はいくつかの問題を見た。あなたのDBプロジェクトフォルダ内の.datファイルは、データベースの一時的なインスタンスと同期しなくなった場合
、スキーマが不正確な結果が得られます比較します。これがどのように起こるかわからない場合は、レビュースキーマを慎重に比較し、問題が発生した場合は.datファイル（ソリューションを終了した後）を吹き飛ばしてください。
データベースが20以上あり、それらが互いに参照して循環参照を使用している場合...その傷ついてしまいます。私はそのシナリオに対してどのようにスケールアップするかを考え出していません。 GDR 2はいくらかの約束を提供するようだ。
Shogこのデータの重要な部分のスキーマの比較についてのコメントに戻って、彼がVS Data Dudeを使用していないことを知らせてください。 – JoshBerke
よろしくお願い致します;-) – JoshBerke