複数のデータベースを使用する場合と単一のデータベースを使用する場合の長所/短所

私は、7つのデータベースを使用する必要がある新しいプロジェクトに取り組んでおり、パフォーマンス、安定性、最適化をより簡単に実装できると主張していました。

私は同意しませんが、単一のデータベースを使用する（テーブルを論理ドメインに分割する）ための適切な引数を収集するのに問題があります。

これまでの議論の1つは、データの整合性です（データベース間で外部キーを使用することはできません）。

単一または複数のデータベースを使用する場合の長所と短所は何ですか？

[これまでの概要]

複数のデータベースに対する引数：

• データの整合性が失われます（データベースで外部キーを使用できません）

• 復元の整合性を失う

• 複雑化（dbユーザー/ロール）

• 小さなオッズのサーバー/データベースがダウンします

ソリューション：

• スキーマを使用してドメインを分離します。

• POC：ダミーデータを使用して7/1 dbの実行計画のポイントを証明する

パフォーマンス、安定性、最適化のいずれも当てはまりません。これらが真実である理由は誰にも確固たる議論や参考記事がありますか？

リソースはデータベースに割り当てられません。SQLServerインスタンスはリソースのバランスをとるため、違いはありません。

あなたが失う：

• データの整合性
• 整合性を復元します（DB7のデータはDB1以降になります）

あなたは複雑になります：

• セキュリティ（ユーザー、ロールなど）はすべてのデータベースに存在する必要があります
• 1つのデータベースにうまく収まらないデータがあります

オプション：

• データベースを個別のディスクに分割するには、ファイルグループを使用します。
• スキーマを使用して、データを論理的に分離します（他の回答に基づいて）

個別のデータベースを作成する十分な理由は、異なる可用性要件をサポートするか、管理を簡素化するためです。たとえば、データベースで非常に異なるバックアップスケジュールまたは異なる復旧モデルが必要な場合。別の理由は、異なるインスタンスで実行したい場合です。

1つのデータベースでは達成できない複数のデータベースで利用可能なパフォーマンスの最適化はありません。「パフォーマンス、安定性、最適化」とはどういう意味ですか？

論理ドメインでデータを分割した後は、SQL2008内のスキーマの使用を常に見ることができます（デフォルトのdboから遠ざかります）。それでも苦痛であり、OR -標準スキーマ。

私は複数のデータベースからのデータを照合する立場にあり、それは苦痛であり、高性能とはほど遠いものです。データをキャッシュするか、少なくともトリックを使用して速度を維持します。

テストとして、7つのダミーデータベースを構築します。7つすべて、または少なくとも十分な数のデータを同時に必要とするクエリを作成します。

次に、実行計画を比較します！すぐそこに勝つと思います。

思考実験：データベースを7個に分割する代わりに、7,000個に分割します。ハードウェア障害がアプリケーションに影響を与える可能性はどのくらいですか？特定の日に特定のサーバーが停止する可能性が0.1％ある場合、依存しているマシンの数を増やしたときにハードウェア障害の影響を受ける可能性は高くなりますか、悪くなりますか？

「データベース」の概念を、スキーマとデータ、データの提供に使用されるハードウェアの2つの部分に分けることが重要だと思います。

データベースを複数のマシンに分割することは、このトピックの他の回答で説明されている多くの理由で役に立ちません。

信頼性とパフォーマンスの向上のために複数のマシンを使用する場合は、クエリを分散するために使用できる複数のウォーム/ホットスタンバイマシンを備えたマスターサーバーを使用できるように構成することができます。この方法では、いずれかのマシンで障害が発生した場合、データを失うことはなく、最悪の場合はクエリを再起動する必要があります。もちろん、これはこれよりも複雑ですが、基本が適用されます。

1つのDBに同意し、代わりにファイルとスキーマのオプションを使用します。

複数のピースに分割することが理にかなっている場合があります。

FTPサーバー、エクスポートファイルパスなどのアプリケーション環境（dev、test、prod）の構成、サーバーごとに保存したいもの、および復元時に上書きされないもの。

また、クライアント固有の手順の変更を分離する方法として。

ただし、これらはサポートであり、パフォーマンスの問題ではありません。