私はいくつかの SQL 環境で働いてきました。ある環境では、ビジネス データを保持するさまざまなテーブルが、すべて同じサーバー上にあるいくつかの異なる SQL データベースに分割されていました。
別の環境では、ほとんどすべてのテーブルが 1 つの SQL データベースに保持されています。
別のプロジェクトと密接に関連する新しいプロジェクトを作成しています。新しいテーブルを同じ SQL データベースに置くべきか、新しい SQL データベースに置くべきか迷っています。
これはすべて MS SQL Server で実行されます。
この決定を下す際には、どのような要因を考慮する必要がありますか?
あなたの質問から、実際の要件が何であるか、または別のデータベースに保存することを検討するデータを判断するのは困難です。しかし、Gordon のポイントに加えて、異なる顧客/ユーザーに属するデータに別々のデータベースを使用する理由をいくつか追加することができます (そして、この回答では、データベースまたはスキーマによるデータの分離の可能性の 1 つを想定しています。顧客によって):
コメントで述べたように、一部の顧客はデータを個別に保存することを要求する場合があり、ペニーを見る前、またはビジネスを保護する前に、書面で同意する必要がある場合があります. したがって、その必然性に備えることもできます。
各顧客を独自のデータベースに保持することで、顧客が現在のサーバーを超えた場合に移動するのが非常に簡単になります. 私の前職では、この方法でシステムを設計し、後でベーコンを保存しました.本質的にメタデータ操作に相当するもので、顧客を別のサーバーに完全に移動することができました. メンテナンス期間中、データベースをバックアップし、元のデータベースをオフラインに設定し、バックアップを新しいサーバーに復元し、そのデータベースの場所をすべてのアプリに通知する構成テーブルを更新しました。これは、他の人が共有するデータベースからすべてのデータを抽出しようとするよりもはるかに柔軟です...
もちろん、これは無料ではありません。トレードオフについてです。複数のデータベースは一部の人々を怖がらせますが、そのようなシステムを13年間管理してきた私は、ほぼ同一の100または500のデータベースを管理することは、1つの大規模なデータベースで500のスキーマを管理するよりもそれほど複雑ではないと言うことができます(実際、私はそれを言うでしょう多くの点でそうではありません）。
データベースはバックアップとリカバリの単位であるため、データベース構造を設計する際に最初に考慮する必要があります。データのバックアップとリカバリの要件が異なる場合、それらは個別のデータベースの非常に優れた候補です。
しかし、それは問題の半分にすぎません。ほとんどの環境では、バックアップ/リカバリはすべてのデータベースでほぼ同じです。それはアプリケーション設計の問題になります。言い換えれば、状況はかなり主観的になります。
私が現在作業している環境では、データをさまざまなデータベースに分割するためのいくつかの基準があります。
（1）幅広い対象者にテーブルを公開する。データをテーブルに「公開」し、それらをデータベースに配置します。これは、データの構築や特別な目的に使用される他のテーブルとは別になります。確かに、SQL Serverは、「スキーマ」がセキュリティの単位であると主張しています。ただし、データベースは現実の世界ではうまく機能しているようです。
（2）厳格なセキュリティ要件。一部のデータは非常に機密性が高いため、弁護士は誰がそれを見ることができるかを承認する必要があります。これは、独自のアクセス権を持つ独自のデータベースに入ります。
（3）データテーブル（ユーザーが表示できる）と本番システムを説明するテーブルの分離。
（4）熟練したアナリストグループによる一般的なクエリに使用されるテーブル（公開されたテーブル）と、特定のレポート/アプリケーションに使用されるテーブルの分離。
最後に、これを追加します。一部のデータが1日を通して継続的に更新され、他のデータがレポートに使用される場合、私はそれらを別のデータベースに配置する傾向があります。これは、問題が発生した場合にそれらを分離するのに役立ちます。