オンライン小売店の加盟システムを構築する必要があります。そのデータベース (MySQL) は、アフィリエイトに次のものを提供する必要があります。
したがって、基本的に2つのオプションがあります。
誰かが私が何をすべきかを説明してもらえますか? また、どちらのバリアントの欠点と利点は何ですか? パフォーマンスに関する考慮事項がいくつかあることは理解していますが、それを裏付けるデータはまったくありません。
すべてを 1 つのテーブルに格納します (キーと値のペアで)
この方法では、MySQL をキー値ストアとして使用しています。この場合、適切に定義されたスキーマがありません。データ スキーマを変更するのは非常に簡単なので、これは利点です。また、データが欠落しているか、一貫性がないことに気付かないため、欠点でもあります。
すべてについて表を作る
これにより、データ構造について考える必要がありますが、すべてのデータをテーブルに収めるのは面倒かもしれません。
テーブルを作ってみることをお勧めします。プロジェクトの開始時にデータ構造について考えるのは良いことです。テーブルを作成すると、データを正しく構造化する必要があります。これが本当にうまくいかない場合は、いつでも 1 つのテーブルまたは何らかの NoSQL ソリューションを使用できます。
アフィリエイトのデータを履歴にして、時間の経過とともにどのように変化したかを確認できるようにする場合は、別のテーブルを作成することをお勧めします。
それを提供したくないと判断し、時間内にスナップショットを提供するだけであれば、それをテーブルに追加することをお勧めします.
個人的には、アフィリエイト ID で参照される別のテーブルを使用して、情報の経時変化のグラフを確認できるようにします。
ここで、たとえば毎週新しい行を保存すると、日ごとの変更や、保存したものよりも短い他の時間間隔を見ることができなくなります。マーケティング アプローチを変更し、その効果を確認したい場合に備えて、製品に基づいてフィルター処理します。
したがって、私はオプション 3 を使用します。これはオンデマンドでデータを取得するため、ユーザーは必要に応じてデータをフィルター処理できますが、週に 1 回実行される標準的なアプローチを使用することもできます。合理的なタイムスライス。
これらの結果を NoSQL データベースにキャッシュします。主な理由は、JavaScript を取得してユーザーに直接送信できるため、取得が高速になるためです。
オンデマンドでデータをプルする必要がある場合は、NoSQL データベースにもキャッシュします。実際のデータベースに移動する前に、要求がそこで満たされるかどうかを最初に確認する場所であるためです。
また、アフィリエイトが独自の選択基準を設定できるようにし、毎日それらのカスタム基準を実行するだけで、情報を取得するためだけに実際のデータベースにアクセスしないようにすることもできます。
アフィリエイトが顧客に影響を与える可能性のあるアフィリエイトからの影響を軽減するために、そのデータベースにアクセスする必要がない限り、アフィリエイトが実際のデータベースにアクセスする必要があることを制限し、その情報を別の場所に置くことが重要です。