お客様のためにいくつかの古いメインフレームアプリケーションを新しいASP.NET + SQL Server 2005アプリケーションに移行しています。各アプリケーションは、一般にスタンドアロンと考えられ、それらの間で共有データはなく、特殊な在庫ニーズや休暇ポリシーを管理するなどの作業を行います。データは小さく、単一のSQL Serverを超えてはなりません。これらのすべてのアプリを共有するための1つの大きなデータベースを作成する方がよいでしょうか？いくつかの小さなアプリケーションデータベースまたは1つの大きなアプリケーションデータベースを作成する必要がありますか？
一般に、アプリケーションごとに1つの小さなデータベースを使用することをお勧めしますが、大規模なデータベースではバックアップとセキュリティの管理が容易になる場合があります。この決定にはどのような要素を考慮する必要がありますか？
アプリごとに小さなdbを使用することを強くお勧めします。 1つのアプリケーションがクラッシュしてテーブルを破損した場合、特定のテーブルのみを選択して復元する必要はありません。落とし込みが可能であることは、今後のメンテナンスや予期せぬアップデートのためにはるかに優れています。
別々のデータベースを使用する必要があります。それらはすべてSQL Serverの同じインスタンスから実行できます。
これらのアプリケーションがデータを共有するかどうかによって異なります。もしそうなら、それらの背後に1つのデータベースを持つ方がよいでしょう。そうでない場合は、将来的にアプリケーションを自由に移動（分離）できるように、それらを分離する方がよいでしょう。
アプリケーションをどのように使用するかを考えてください。 1つのデータベースがあり、たとえば顧客用に1つのテーブルがある場合、複数のアプリケーションが同じテーブルにアクセスすると、ロックの問題が発生する可能性があります。
データストアにアプリ間の重複がない場合は、アプリごとに1つのデータベースアプローチを使用します。そうすれば、現在のデータベースサーバのうちの1つが、現在のデータベースサーバよりも先に進めば、それを比較的簡単に自分のサーバに移動することができます。
また、バックアップ/リストアの観点からは、単一のアプリケーションのデータベースを復元して、セット全体を復元するのではなく（単一のデータベースに格納されているため）実際にサービスを復元するために必要なビットを取得します。
複数のカタログを内部に持つ1つのデータベースを作成することをお勧めします。各カタログは独立しており、別々のデータベースとして理解されていますが、同じソリューションの下でバックアップや管理などの前述の利点があります。その後、各カタログには独自のデータテーブルなどが含まれます。カタログは、テーブルのように互いにデータを関連付けません。