私たちは、選択したストレージソリューションからクライアントの顧客データを取得し、サーバー上でデータを処理するSaaS企業であり、クライアントにログインして、付加価値のある顧客データを表示します。
複数のクライアント
さまざまなAPIとソースを介してプルしているため、データのローカルコピーをMySQLサーバーに保存します。現在の（明らかに欠陥のある）アーキテクチャは、取得したデータを、名前以外はすべて同一である個々のクライアントテーブルに格納することです。これは、a）予期しない成長、およびb）クライアントデータを完全に分離して、あるクライアントが共有クライアントテーブルから別のクライアントのデータを見る可能性が正確に0％になるようにする最初の試みの結果です（通常、クライアントは競合他社です）。だから私たちは持っています：
table client_ABC
- field A
- field B
- ...
- field N
table client_XYZ
- field A
- field B
- ...
- field N
スケーリングするにつれて、上記は予想通りに表面化しています-何十もの同一のクライアントテーブルを追加しており、スキーマへの変更は悪夢です。私はデータを単一のテーブルに結合し、「クライアント」列を追加することに傾倒していますが、この質問のパート2は、その中で物事を複雑にする可能性があります...
一貫性のない/一意のクライアントデータ
2番目の問題は、プルするデータがクライアントごとにほとんど共通していないことです。各クライアントのデータにはいくつかの共通要素（名前、電子メール）がありますが、残りのデータは異なり、一部のクライアントのデータにはアドレス情報が関連付けられており、一部のデータには詳細な購入記録があります。
現在の解決策は、上記のクライアントテーブルにいくつかの一般的な「メタ」フィールドを含めることです。これらのフィールドをクライアントごとにマッピングして、ビジネスロジックがクライアントABCの顧客を表示しているときに次のようにします。
customer ABC
- name -> name
- email -> email
- street -> meta_1
- city -> meta_2
クライアントXYZの場合、次のようになります。
customer XYZ
- name -> name
- email -> email
- last purchase -> meta_1
クライアントを追加すると、フラットでない顧客データ（つまり、完全な販売記録）を持つクライアントが見つかります。追加のデータを格納するためにカスタムのセカンダリクライアントテーブルを追加する必要があるため、上記のソリューションは失敗します。
これらはすべて、共有コード/ビジネスロジックを介してすべてのクライアントに公開されることに注意してください。
1つの考えは、個々の顧客データをJSONなどの二次構造の汎用データ列に格納することです。これにより、次のようになります。
table client
- name = "Bill Smith"
- email = "bsmith@example.com"
- data = { "street": "123 Fake St", "city": "Big City"}
ここでの問題は、フルテキスト検索、インデックス作成などをどのように行うかです。
これらの2つの関連する問題に取り組み始める方法についての提案はありがたいです！