複数のクライアント向けに設計されたデータベース中心のアプリケーションでは、すべてのクライアントに対して単一のデータベースを使用する (レコードを適切なインデックスとキーに関連付ける) のが「より良い」と常に思ってきました。Stack Overflow ポッドキャストを聞いていると、Joel が FogBugz はクライアントごとに 1 つのデータベースを使用する (つまり、クライアントが 1000 台ある場合は、データベースも 1000 台ある) と言っているのを聞きました。このアーキテクチャを使用する利点は何ですか?
一部のプロジェクトでは、クライアントがすべてのデータに直接アクセスする必要があることは理解しています。このようなアプリケーションでは、各クライアントに独自のデータベースが必要であることは明らかです。ただし、クライアントがデータベースに直接アクセスする必要がないプロジェクトでは、クライアントごとに 1 つのデータベースを使用することに利点はありますか? 柔軟性の点では、テーブルのコピーが 1 つある単一のデータベースを使用する方がはるかに簡単なようです。新しい機能の追加やレポートの作成が簡単になり、管理も簡単になります。
私は、経験豊富な開発者である Joel が彼のソフトウェアでは別のアプローチを使用していると述べるまで、「すべてのクライアントに 1 つのデータベース」方式にかなり自信がありましたが、彼の決定には少し困惑しています...
レコード数が多いとデータベースの速度が低下するという意見を聞いたことがありますが、ある程度のメリットがあるリレーショナル データベースでは、特に適切なインデックスとキーが使用されている場合は、そのような問題は発生しません。
ご意見をいただければ幸いです。
ベストアンサー1
すべてのクライアントを 1 つのデータベースに保存してもスケーリングのペナルティは発生しないと仮定します。ほとんどの人にとって、また適切に構成されたデータベース/クエリにとっては、これは今日ではほぼ当てはまります。あなたがこれらの人々の 1 人ではない場合、単一のデータベースの利点は明らかです。
このような状況では、各クライアントのカプセル化によってメリットが得られます。コードの観点からは、各クライアントは独立して存在します。データベースの更新によって、別のクライアントに属するデータが上書き、破損、取得、または変更される可能性はありません。また、レコードが別のクライアントに属する可能性があるという事実を考慮する必要がないため、モデルも簡素化されます。
また、分離性の利点も得られます。特定のクライアントに関連付けられたデータを取り出して、別のサーバーに移動するのは簡単です。または、組み込みのデータベース メカニズムを使用して、「重要なデータを削除しました」という通知があったときに、そのクライアントのバックアップを復元することもできます。
簡単かつ無料のサーバー モビリティが実現します。1 つのデータベース サーバーを拡張すると、別のサーバーで新しいクライアントをホストできます。すべてが 1 つのデータベース内にある場合は、より強力なハードウェアを入手するか、複数のマシンでデータベースを実行する必要があります。
バージョン管理が容易になります。あるクライアントがソフトウェア バージョン 1.0 を維持したいが、別のクライアントが 2.0 を希望している場合、1.0 と 2.0 が異なるデータベース スキーマを使用していても、1 つのデータベースからそれらを取り出すことなく移行できるため、問題はありません。
他にも数十個くらい思いつくと思います。しかし、全体として、重要な概念は「シンプルさ」です。この製品は 1 つのクライアント、つまり 1 つのデータベースを管理します。「データベースには他のクライアントも含まれています」という問題による複雑さはまったくありません。これは、ユーザーが単独で存在するというユーザーのメンタル モデルに適合します。すべてのクライアントについて一度に簡単にレポートを作成できるなどの利点は最小限です。1 つのクライアントだけではなく、世界全体のレポートが必要になる頻度はどれくらいでしょうか。