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

Question

私は、SaaSとして提供したいトラック輸送会社のために構築したWebアプリを持っています。データベースを設計する最良の方法は何ですか？

各会社に新しいデータベースを作成する必要がありますか？または、会社名のプレフィックスがあるテーブルを備えた1つのデータベースを使用する必要がありますか？または、各テーブルのいずれかを含む1つのデータベースを使用して、テーブルに会社IDフィールドを追加するだけですか？それとも、それを行う他の方法はありますか？

Answer 1

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

-ドン

Answer 2

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

はい - ドン・ディキンソンはお金を使っていました。ただし、以下の洗練を参照してください。

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

主よ！クライアント用の異なるためにデータベースクエリを変更すると、狂気になります！また、ほとんどのサーバーがクエリプランと暫定結果をキャッシュすることを好むため、ほぼ確実に動的SQL（クエリを実行する前にコードでテーブル名が変更されている場合）を実行します。変化し続けます。

または、各テーブルのいずれかを含む1つのデータベースを使用して、テーブルに会社IDフィールドを追加するだけですか？

顧客のために何らかのスケーラブルなモデルを持ちたい場合は、これを行うことをお勧めします。顧客ごとに新しいデータベースをプロビジョニングすることで、多くの柔軟性が得られますが、コストと複雑さも伴います。新しいバックアップスケジュールを作成し、期限切れの顧客などを扱うためのライフサイクルモデルを持っている必要があります。

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

私は数年前にSaaSの会社で似たようなことをしました - そして、顧客は通常、インフラストラクチャ（読み取り：パフォーマンスと回復力）にアップグレードされたパスを持っていることを喜んでいます。

Answer 3

クライアントごとに単一のデータベースを使用することの利点は何ですか？

マルチクライアントアプリケーションには、単一または複数のデータベースセットアップを使用する必要がありますか？

https://stackoverflow.fogbugz.com/default.asp?w24218 （ポッドキャストの成績証明書、約50分間の議論）

Answer 4

ここには、共有クライアントを使用したデータベースがあり、各クライアントには独自のサーバーと独自のデータベースがあります。クライアントが自分のサーバー上にいる場所は、管理が最も簡単で、一部の開発者がclientidIDを追加するのを忘れてクライアントAのデータを偶然クライアントBに送信した場合に問題を引き起こす可能性が最も低いです（ランダムに選択されていない例）。

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

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

Answer 5

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