データベースベースのアプリケーションを開発するための最良の方法は何ですか？2つのアプローチがあります。
それぞれの長所と短所は何ですか？そして、どちらがより良い方法ですか？
編集：複数の開発者がデータベースを更新することになっており、各開発者のマシンにはすでにSqlExpress2005があります。
編集：私たちのほとんどは、共通のデータベースを提案しています。ただし、開発者の1人がコードとデータベーススキーマを変更した場合。彼はコードの変更をコミットしていませんが、スキーマの変更は共通データベースに反映されています。他の開発者のコードを壊すことはないでしょうか。
両方 -
私は、変更が公開される前、または「正式な」テスト環境に移行する前に変更がテストされる単一のデータベースが好きです。これは開発者の健全性チェックです。ライブシステムを常に最新の状態に保ち、常にお互いの変更を考慮していることを確認します。ルールは、他の何かを壊す可能性がある場合、変更はここでは行われないということです。
複数の開発者が更新を行っている場合、開発者ごとのデータベースは優れています（不可欠ですら）。それは彼らが他の開発者のために物事を壊すことなく彼らが望むすべての開発の柔軟性を可能にします。
重要なのは、データベースの変更を開発からライブシステムに移動するプロセスを用意し、そのプロセスに固執することです。
共有データベース
個々のデータベース
共有開発データベースを使用しており、うまく機能します。私たちのスキーマは、後方互換性がなくなるような方法で変更されることはめったにありませんが、実際に稼働する前に設計変更が発生することがあり、他の開発者に更新を依頼するだけです。
個別の開発アプリケーション（Web）サーバーがありますが、それらは同じデータベースを共有しています。私たちの開発者は、これを設定する方法を知っているので、独自のデータベースを使用するオプションがあり、それを時々行いますが、一時的です。私たちにとっての標準は、データベースを共有することです。
私はこれを捨てると思いましたが、すべての開発者が自分のデスクトップでSQL Server Developerの独自のインスタンスをホストし、他の各環境（開発、QA、および製品）用の共有サーバーを使用できるようにしてはどうでしょうか。Visual Studio Proに付属している基本的なMSDN（選択した場合）にも、SQLServerDeveloperのライセンスが含まれていると思います。
開発者は他の人に影響を与えることなくデスクトップで作業でき、その後、適切と思われる次の共有環境にコードを移動させることができます（自由に、毎日/毎週のビルドなどで）。
編集： デスクトップインスタンスを使用すると、開発者はDBAが共有環境で頻繁に制限することを実行できます。これには、データベースの作成、バックアップ/復元、プロファイラーなどが含まれます。これらは必須ではありませんが、開発者がDBAに対する要求を減らしながら、生産性を大幅に向上させることができます。
テストには共有環境が完全に必要です。デスクトップから本番環境に移行することはお勧めしません。ただし、開発者が特定のデータベース環境（他のデータベースからの分離を含む）を比較的わずかなコストで100％制御できるようにすることで、多くを追加できます。
開発、テスト、およびメンテナンスのサイクルによって異なります。また、開発チーム（そしてもちろん組織）の規模と場所についても説明します。データベースの複数のバージョンをサポートしている場合は、さらに多くの環境が必要になる可能性があります。
現実の世界では、次のアプローチはかなり満足のいくものであることがわかりました。
ここにいくつかのさらなるポイントがあります：
2人の開発者（2つのチーム）が互いに影響を与える可能性のある変更に取り組んでいる場合は、タスクを個別に完了してから、統合/マージしてテストする必要があります。このためには、別々の開発環境を用意する方がはるかに優れています（一緒に作業する必要がある場合を除き、同じチームの一部であると見なします。それでも、データベースの独自のコピーで作業し、必要に応じて共有できます）
相互に影響を及ぼさない変更に取り組んでいる場合は、メインサーバーで作業できます。または、データベースの独自のローカルコピー。
したがって、ローカルコピーで開発することには、一般的なケースではリスクなしですべての利点があります（システムの複数のバージョンをサポートし、とにかくアップグレードスクリプトを維持する場合）。
それでも、テストケースを共有できれば素晴らしいので、データベースを簡単かつ迅速にダンプ/復元できることは大きなプラスです。
編集：
上記のすべては、テスト目的（サイズ、パフォーマンス、ライセンスなど）のためにシステム全体のローカルマシンにコピーを置くことが可能であることを前提としています。
いったいなぜ、すべての開発者のために個別のデータベースが必要なのですか？すべてに共通のデータベースを1つ用意します。そうすれば、テーブル構造に一貫性があり、SQLステートメントにも一貫性があります。
私は解決策＃1を選びます：すべての開発者のための1つの共通データベース。
長所
短所
ソリューション＃2について：開発者ごとに1つの独立したデータベース。
長所
短所
上記を考慮して、会社の規模に応じて、次のことをお勧めします。
あなたの会社が統合テストを必要としない場合は、受け入れテストを行ってください。このステップは、本番環境に移行する前に重要です。
私たちは両方を行います：
私がいる場所ではコード生成を使用し、データベースも生成されます。したがって、データベースが生成される各開発者のボックスにインスタンスがあります。次に、生成されたスクリプトを使用して、変更を中央テストデータベースに適用します。それがうまくいけば、リリース中に本番データベースに変更を適用します。
このアプローチの優れている点は、「信頼できる情報源」がソース管理にチェックインされると、データベースのすべての変更が、他の開発者がリベースおよび再生成するときに自動的に配布されることです。それは私たちにとってうまくいきます。
開発者ごとに1つと、ユニットおよび統合テストを実行するための継続的インテグレーションおよびビルドサーバー。それはあなたに両方の長所を与えます。
すべての開発者が単一の開発データベースを変更すると、データベースの変更量が特定のレベルに達すると、開発者はチェックインの準備ができる前に共有データベースに変更をデプロイする必要があるため、生産性がすぐに低下します。つまり、コードの他の部分が必要になります。回線が不必要に途切れる場合があります。
簡単な答え：
1つの開発データベースがあり、開発者が独自のデータベースを必要とする場合は、独自のマシンで独自のインスタンスを実行できます。必ず共有でテスト/公開してください。
最善の方法は、Test / QAサーバー上の単一のデータベースと各開発者用の1つのデータベース（おそらく開発者のローカルコンピューター上）です（したがって、10人の開発者が10 + 1個のデータベースで作業します）。
一般的な開発と同じアプローチ：各開発者はローカルマシン上にソースコードの独自のコピーを持っています。
また、複数データベースのアプローチにより、バージョン管理システムでのデータベーススキーマの保持が簡素化されます。データベース作成スクリプトはSVNに保管しています。
ここで説明されているアプローチを使用しています： http ：//www.sqlaccessories.com/Howto/Version_Control.aspx
また、データベースのリファクタリングも検討することをお勧めします。データベースの変更について説明するほかに、リスクを軽減する方法で開発から本番環境に移行することについての説明も含まれています。
独自のデータベースを持つ開発者の最大の問題は次のとおりです。
あなたが他人に影響を与えることを知っているとき、私はあなたが私の本の中でプラスであるあなたが何をするかについてもっと注意する傾向があると思います。
これで、共有データベースサーバーには、スクラッチデータベースと呼ばれる、テーブルの変更を作成およびテストできる場所が必要になります。したがって、テーブルを削除して再作成する必要がある場合（まれなケースです！）、最初にテーブルをスクラッチデータベースにコピーしてそこでプロセスを実行し、それが機能することを確認したら実際のデータベースに変更することで、プロセスをテストできます。または、特定の変更をテストする前にバックアップテーブルをスクラッチデータベースにコピーすることがよくあるため、問題が発生した場合に古いデータを簡単に再作成できます。
個々のデータベースを使用することにまったく利点はありません。