これは愚かなやり方ですが、私の会社が行っていることです...私たちはdevでスキーマを変更します。そこで、本番SQL 2008データベースを手動で開き、デザイナーを使用して関連する修正を加え、新しいコードを展開してから最高のものを願っています。時には、明らかに大きな頭痛につながる可能性のあるスキーマを変更することを忘れてしまいます。だから、確かに良い方法がありますか？理想的には、スキーマの変更を識別して展開するのに役立ついくつかの無料ツールが必要ですが、そのようなことが存在することに気づいていません....devとprodの間のスキーマの変更を扱う
VS2010でASP.NETを使用しています。
Writing and Changing Database Codeを参照してください。
私はupgrade scriptsを提唱しています。アップグレードスクリプトとして、常にの変更をマイナーな方法で行う必要はありません。次に、プロダクションに移行するときは、アップグレードスクリプトをバージョンNからバージョンN + 1に実行するだけです。効果的にすべての「ビジュアル」データベース設計/管理ツールを禁止する。
この方向には、コードの最初のORM、database GDR project、diff based配備など、さまざまな取り組みがあります。個人的には、明示的なアップグレードスクリプトが長期的にはるかに優れた選択肢であることがわかります。
Team Foundation Serverには、ビルドごとにデータベーススキーマの変更を格納して解放する方法があると思います。それを超えて、私はRemus Rusanuに同意します。すべての変更はスクリプト化され、appliationの各バージョンと共にリリースされるバージョンスクリプトに入れなければなりません。
VS2010のこのスキーマ比較ツールはどうなっていますか：http://www.mssqltips.com/tip.asp?tip=2089これはdevとprodのスキーマを比較してアップグレードスクリプトを自動的に与えるようですね?? – Headache
これはvsdbcmdによって強化されたVS GDRです。http://msdn.microsoft.com/en-us/library/dd193283.aspx diffベースのツールの私の問題は、私が1つを使用したときに始まり、SELECT ... INTOおよびsp_rename（これは、ほとんどの差分ツールが行うトリック）によってテーブルを変更することを無邪気に提案していました。テーブルには160Bnの行があり、ディスクには1.5TBでした。このため、私はアップグレードスクリプトを使用するのではなく、何が起こるか正確に知っています。また、スクリプトはソース管理にチェックインされ、変更の履歴があります。 –
あなたが単に（ツールが完璧な仕事をしていると考えるならば）あなたの現在の開発者が何であれ、最終的にprodにdiffするのであれば、あなたは終わります。変更の追跡と変更の履歴の問題と同様に、*開発者は間違いを犯してdevdb *を残していないと仮定しています。 –