1つのデータベースと複数のデータベース
複数の「プロジェクト」を表すシステムを設計する必要があります。SQLServerのクライアントごとに1つ、StackExchangeに似たものです...同じデータモデル、異なるサイト（顧客ごとに1つ）。各プロジェクトのデータモデルは同じですが、他のすべてのプロジェクトから独立しています。私の傾向は、1つのデータベースを使用してすべてのプロジェクトを保存することです。あなたの推薦は何ですか？
別のデータベースを作成します。そうしないと、各クライアントが同様のスキーマを使用している場合、テーブルを組み合わせるか、多くのプレフィックスを使用するか、クライアント識別情報を含むリンクテーブルを作成する必要があります。さらに、クライアントデータに独自のDBがある場合、クライアントデータのバックアップ/復元の管理がはるかに簡単になります。
別々のDB、IMOを使用しない理由は本当にありません。
個別のデータベースの欠点の1つは、スキーマの変更を展開することです。数百のデータベースがある場合は、新しいテーブル、ストアドプロシージャ、それらにアップグレードするためのインデックスをプッシュする賢い方法を見つける準備をしてください。もう1つの欠点は、データベースの数が増えるにつれて、ミラーリングがDRソリューションにとって魅力的でなくなることです。
私はMSSQLを使用していませんが、原則として、顧客ごとに1つのDBを使用しています。扱いがはるかに簡単です。さらに、1つのデータベースが失敗しても、それが発生しても、他の顧客には影響しません。メンテナンス手順は、1つと同じくらい簡単に複数のデータベースに対してスクリプト化できます。
データを1つの場所に保持する緊急の必要性がない限り、データを分離することをお勧めします。サーバー間でのデータの移動が簡単になります（たとえば、負荷が問題になるまでデータを複数のデータベースサーバーに分割したい場合、またはクライアントがアプリを社内に持ち込むためにお金を払いたい場合）、バックアップとその後の復元をより便利にすることができ（使用するバックアップ方法に応じて、またはもちろん）、クライアントが（偶然または意図的にハッキングして）お互いのデータを見ることができるコードバグのリスクを軽減します。
ここに正しい答えはありません。 purist-dbaルートはすべて1つのDBにあります。あなたがdesign/config/sqlに長けているなら、あなたはあなたが1つの現代の〜$ 8Kサーバーから何を得ることができるかに驚くでしょう。安くて汚いウェブスケーリングルートは1：1のcustomer：dbです。そうすれば、顧客が他の顧客よりも非常に人気が高まった場合に、顧客を分割してセットアップを拡張できます。純粋なWeb開発者のルートは「1つの」データベースですが、bigtable/dynamoのような方法で拡張できます。
それは実際には技術的な問題ではなく、ビジネス上の問題になります。現在、開発者と管理者は何人いますか、彼らはどれほど才能がありますか、彼らはすでに何を知っていますか、非常に短期的にはどのようなトラフィックを期待していますか、ハードウェアの10倍の購入/リースにはどのような収益が必要ですかそのためなど。
全体的に見て、古いスタートアップの手はほとんど「ただそれを機能させて集中する」と言うでしょう。
編集：また、これが質問をするシステム管理者である方法はありません。開発者は常に、「万が一に備えて」サーバー構成の複雑さを10倍にする設計を考えたいと思っています。
私は顧客ごとに1つのデータベースを使用してきましたが、前述のように、スキーマとバックアップの更新には注意が必要です。
しかし、それほど多くはありません。
すべてのデータベースを個別に（少なくとも別のマシンではないにしても別のデータベースに）ログに記録し、schema_update_logなどと呼ばれるテーブルを用意し、すべてのデータベースのスキーマを更新して成功をログに記録するスクリプトを作成する必要があります。したがって、100,000のデータベースがある場合、多くの物理サーバーにまたがって、それぞれにクエリを実行して成功をログに記録します。何らかの理由で失敗した場合は、失敗したデータベースを再試行します。
したがって、次のようになります。
master_databases :(クライアントごとのすべてのデータベースのレコードとその接続文字列）db_idデータベース.。
schema_update_log pk query_id db_id status（pending、success、failed）タイムスタンプエラー（念のため）
schema_query query_id（schema_update_logで参照）query
次に、各dataasemクエリと更新ログをループするスクリプトを記述し、すべてのquery_idに対して、すべてのデータベースがschema_update_logで成功を返すまで実行し続けます。
これには時間がかかりますが、アドホック更新よりも信頼性が高くなります。
個別のDB。与えられた他の理由に加えて：
- それ以外の場合、クエリにはすべて「AND project_id = $ project_id」を含める必要があります。
- 機密性の管理、個々の顧客の記録の保存などがはるかに簡単です（特定の顧客のデータベースを定期的にアーカイブすることをお勧めします）
- 個々の顧客向けの機能の追加に成功した場合は、その顧客専用のスキーマ変更を追加できます（または少なくともオプションがあります）
- ある顧客から別の顧客にデータが漏洩する危険はありません
基本的に、それははるかにクリーンまたはより正確です。テーブル内の行が互いにまったく関係がない場合、それらは一緒にテーブル内にあるべきではありません。 （わかりました、私はちょうどそのルールを作りました。）
セキュリティの観点からコンテンツをより高度に分離するためには、顧客ごとに1つのデータベースが魅力的だと思います。
一方、より多くの顧客を処理したい場合は、コストがかかると思います。もちろん実行できるあらゆる種類のdbアップグレードを処理するために追加のインフラストラクチャを提供する必要があるためですが、誰かが実際に座って方法を考えてみてください。ほとんどの場合、それは半分手動で行われることになります。複数の顧客がいると、スケーリングが不十分なコードの欠点がすぐにわかります。これは、何年も持ち越さないため、良いことです。
また、クライアントごとに追加のインスタンスや環境を設定せずにサービスのドメインを考えるだけでよいため、モノリスからマイクロサービスアーキテクチャに移行する際の作業も簡単になります。無制限の開発者は存在せず、雇用する必要のある追加の人が増えるほど、常に心に留めておく必要があります。経済的な答えも申し訳ありませんが、このような質問には必要だと思います。
また、セキュリティについても触れておきたいと思いますが、それだけではありません。最終的には、より環境にやさしい->ハードウェアの削減->電力の削減->消費電力の向上にも努める必要があるからです。クライアントごとに参照があるだけでは、特にSQLの場合はそれほどコストがかかりません。リレーショナルDBは結合用に作成されます。
ケージナットが言うように、それは異なります。しかしながら...
クライアントごとに1つのデータベースがあると、長期的には自分にとって物事が難しくなる可能性があります。最終的に100,000のクライアントが発生した場合はどうなりますか？ SQL Serverはその数のデータベースに対応しますか？最終的に100,000のデータベースバックアップが作成されますか？それをどのように管理しますか？これで作業が増える場合、後で変更できるのであれば、なぜ今そのオプションを選択するのですか？
今は単一のデータベースを使用することも考えられますが、クライアントが非常に多い場合にデータを分割する方法を考えてください。