複数のデータベースを使用する場合と単一のデータベースを使用する場合の長所/短所
私は、パフォーマンス、安定性、最適化をより簡単に実装できると主張して、7つのデータベースを使用する必要がある新しいプロジェクトに取り組んでいました。
同意しませんが、単一のデータベースを使用するための適切な引数を収集することに問題があります（テーブルを論理ドメインに分割）。
これまでの議論の1つは、データの整合性です（データベース間で外部キーを使用できません）。
単一または複数のデータベースを使用する場合の良い点と悪い点は何ですか？
[これまでの要約]
複数のデータベースに対する議論：
データの整合性が失われます（データベースで外部キーを使用できません）
復元の整合性を失う
複雑化（dbユーザー/ロール）
小さなオッズサーバー/データベースがダウンします
ソリューション：
スキーマを使用してドメインを分離します。
POC：ダミーデータを使用して7/1 dbの実行計画の要点を証明する
パフォーマンス、安定性、最適化はどれも正しくありません。誰がこれらが真実であるのか、確かな議論や参考記事を持っていますか？
リソースはデータベースに割り当てられません。SQLServerインスタンスはリソースのバランスをとるので、差なしになります。
あなたが失う：
- データの整合性
- 整合性を復元します（DB7のデータはDB1より後になります）
複雑さが増します：
- セキュリティ（ユーザー、ロールなど）はすべてのデータベースにある必要があります
- 1つのデータベースにうまく収まらないデータがいくつかあります
オプション：
- データベースを個別のディスクに分割するには、ファイルグループを使用します。
- スキーマを使用してデータを論理的に分離する（他の回答に基づく）
論理ドメインでデータを分割した後は、SQL2008内のスキーマの使用を常に見ることができます（デフォルトのdboから離れます）が、それでも苦痛であり、OR/Mで問題が発生し、非-標準スキーマ。
私は複数のデータベースからデータを照合する立場にありましたが、それは苦痛であり、高パフォーマンスにはほど遠いものです。データをキャッシュするか、少なくともトリックを使用して速度を維持することになります。
テストとして、7つのダミーデータベースを作成します。 7つすべて、または少なくとも適切な数のデータを同時に必要とするクエリを作成します。
次に、実行計画を比較してください！私はあなたがすぐにあなたの訴訟に勝つと思います。
別個のデータベースを作成する理由は、さまざまな可用性要件をサポートするか、管理を簡素化することです。たとえば、データベースに非常に異なるバックアップスケジュールまたは異なる復旧モデルが必要な場合。別の理由は、それらを異なるインスタンスで実行したい場合です。
複数のデータベースで使用できるパフォーマンスの最適化はありませんが、1つのデータベースでは達成できません。 「パフォーマンス、安定性、最適化」の意味を詳しく教えてください。
思考実験：データベースを7つに分割する代わりに、7,000に分割します。ハードウェア障害がアプリケーションに影響を与える可能性はどの程度ですか？特定の日に特定のサーバーが停止する可能性が0.1％ある場合、依存しているマシンの数を増やすと、ハードウェア障害の影響を受ける可能性は高くなりますか、それとも悪くなりますか？
「データベース」の概念を2つの部分に分割することが重要だと思います。スキーマとデータと、データの提供に使用されるハードウェアです。
複数のマシンにまたがってデータベースを分割することは、このトピックの他の回答で説明されている多くの理由のために役に立ちません。
信頼性とパフォーマンスを向上させるために複数のマシンを使用する場合は、複数のウォーム/ホットスタンバイマシンを備えたマスターサーバーを構成して、クエリを分散することもできます。この方法では、いずれかのマシンで障害が発生した場合、データが失われることはなく、最悪の場合、クエリを再起動する必要があります。もちろん、これはもっと複雑ですが、基本は当てはまります。
私は1つのDBに同意し、代わりにファイルとスキーマのオプションを使用しています。
複数の部分に分割することが理にかなっているEdgeのケースがあります。
FTPサーバー、エクスポートファイルのパスなどのアプリケーション環境（dev、test、prod）の構成、サーバーごとに保存するもの、および復元時に上書きされないもの。
クライアント固有の手順の変更を分離する方法としても。
ただし、これらはサポートであり、パフォーマンスの問題ではありません。