これが「サービスとしてのソフトウェア」カテゴリ全体に分類されることに気づいていなかったので、用語の一部が少し間違っている可能性があるため、ここで私に耐える必要がありますが、ここではそうです。
クライアント用のメンバーシップシステム（PHP）を開発しました。現在、サブドメイン（または独自のドメイン）を提供する、他のクライアント向けの完全にホストされたソリューションとして提供することを検討しています。
データストレージに関する限り、私がテーブルに持っていると思われるオプションは次のとおりです。
オプション1-すべてを1つの大きなデータベースに格納し、それを必要とするテーブルに「client_id」フィールドを設定し（適用されるテーブルは約30個あります）、メイン設定と詳細を格納する「clients」テーブルを設定します、などとそれらにマップするドメイン。次に、個々のクライアントIDを含むグローバルにアクセス可能な変数を設定します。client_id列を確認するために、すべてのクエリを変更する必要があることは明らかです。
オプション2-「共有参照」テーブルと「クライアント」テーブルを含むマスターテーブルを用意します。次に、他のデータベースの「ブロック」を作成します。各データベースには、たとえば10個のクライアントが含まれています。クライアントは、クライアントIDのプレフィックスが付いた独自のデータベーステーブルを取得します。これにより、何かが本当にうまくいかなかった場合に他のクライアントデータが表示されないように保護するためのセキュリティが少し追加されます。
オプション3-オプション2とまったく同じですが、クライアントごとに1つのデータベースがあり、他のクライアントから完全に分離されており、理論的には、1つのクライアントのテーブルがハッキングされたり、その他の方法で破損したりしても、もう少し保護されます。他の誰かに影響を与えます。最大の欠点は、新しいクライアントを展開するときに、データベース全体、ユーザーとパスワードを設定する必要があることです。これにより、かなりのオーバーヘッドが発生する可能性があります。または、全員が1人でいる場合とほぼ同じです。データベース？
いくつかのポイントも-これらのクライアントの一部には5000以上の「顧客」とそれらの顧客のすべての詳細があります-これがオプション1が少し問題になる理由です-100のクライアントがある場合、それは等しい可能性があります1つのテーブルに50万行を超える行。
顧客データ（および支払い情報）のセキュリティが重要な状況では、オプション3が最善の方法であると私は考えていますか。私が持っていた推奨事項から、「簡単」という理由でオプション1を選択すると言う人もいますが、実際にはそのようには見えません。クライアントが独自のデータベースを持っていれば、クライアントをはるかに簡単に移動できるので、これは将来の潜在的なボトルネックだと思います。
（FYIシステムはMySQLをベースにしたPHPです）