database - SaaS データベースの設計方法

Question

SaaS として提供したい運送会社向けに構築した Web アプリがあります。データベースを設計する最良の方法は何ですか?

会社ごとに新しいデータベースを作成する必要がありますか? それとも、会社名の接頭辞を持つテーブルを持つ 1 つのデータベースを使用する必要がありますか? または、各テーブルの 1 つで 1 つのデータベースを使用し、テーブルに会社 ID フィールドを追加するだけですか? または、それを行う他の方法はありますか？

Answer 1

約 10 年前に同様の状況に直面したとき、私たちはクライアントごとにデータベースを選択しました。数百 (数千ではない) のクライアントがいます。振り返ってみると、それは私たちが下した最良の決定の1つでした. バックアップは簡単です。分析のために 1 つのクライアントをオフィスにコピーするのは簡単です (最後のバックアップを取るだけです)。スケーリングは簡単です (単一の大きなクライアントを別のサーバーに移動すると、負荷の高い SQL サーバーのリソースを解放できます)。joel と jeff はスタック オーバーフロー ポッドキャスト(最近のものではない) でこれについて議論し、joel は私と同じことをしました...各クライアントは独自のデータベースを取得します。データベースの純粋主義者は、全員を 1 つのデータベースにまとめることを主張することがよくありますが、私は決してそうしません。

-ドン

Answer 2

会社ごとに新しいデータベースを作成する必要がありますか？

はい-ドン・ディキンソンがお金を稼いでいました。ただし、以下の改良点を参照してください。

または、会社名のプレフィックスが付いたテーブルを持つ1つのデータベースを使用する必要がありますか？

主よ！クライアントごとにデータベースクエリを変更すると、気が狂ってしまいます。また、ほぼ確実に動的SQL（クエリを実行する前にコードでテーブル名が変更される）を実行します。これは、ほとんどのサーバーがクエリプランと中間結果をキャッシュすることを好むため、パフォーマンスを低下させます。これは、テーブル名の場合は機能しません。変化し続けます。

または、各テーブルの1つで1つのデータベースを使用し、会社IDフィールドをテーブルに追加する必要がありますか？

顧客のためにある種のスケーラブルなモデルが必要な場合は、これを行うことをお勧めします。顧客ごとに新しいデータベースをプロビジョニングすると、柔軟性が大幅に向上しますが、コストと複雑さも伴います。新しいバックアップスケジュールを作成し、期限切れの顧客に対処するためのライフサイクルモデルを用意する必要があります。

つまり、「無料トライアル」と「ブロンズ」の顧客はすべて、会社IDを使用してそれらを分離し、単一のデータベースにまとめられていると言えます。「シルバー」ユーザーは独自のデータベースを取得し（ただし、スキーマにcustomer_idフィールドを保持するため、2つのレベルの顧客間でクエリを変更する必要はありません）、「ゴールド」ユーザーは独自のデータベースサーバーを取得します。

私は数年前にSaaSの会社で同様のことをしました。顧客は通常、機能だけでなくインフラストラクチャ（パフォーマンスと復元力）のアップグレードパスを持っていることを喜んでいます。

Answer 3

ここには、共有クライアントを持ついくつかのデータベースと、各クライアントが独自のサーバーと独自のデータベースを持つデータベースがあります。クライアントが独自のサーバー上にあるものは、管理が最も簡単で、一部の開発者が clientid を追加するのを忘れて、クライアント a のデータを誤ってクライアント b に送信した場合に問題が発生する可能性が最も低くなります (ランダムに選択された例ではありません)。

それぞれを独自のサーバーまたはサーバーインスタンスに保持することで、データベース構造を同じ名前で同じに保つことができ、データベース名を変更する必要がないため、変更をすべてのサーバーに簡単に伝達できます。

クライアントごとに個別のインスタンスを使用する場合は、すべての変更をすべてのクライアントに伝達するための適切なシステムを設計および実装してください。これらのデータベースが同期しなくなると、維持が困難になる可能性があります。それらが同期しなくなると、各クライアントが変更を要求し、同じことを行う方法が 27 通りあることがわかります。それらが同じデータベース上にある場合は一般化する必要があり、それらが別々の場合は自己規律を使用して、新しい機能が各クライアントで同じであることを確認する必要があります。

Answer 4

ここで、私は他の会社のように扱われる多くの「内部ビジネスユニット」を持つ会社で働いています。そのため、一部のレポートにはすべての企業を含める必要があり、クライアント アカウントも企業間で共有する必要があります。ここでは、それを必要とするテーブルに CompanyId フィールドがあります。Prefix ソリューションは、避けるべきものです。