Web サイトには友達を招待するための機能モジュールが必要です。プロセスは次のとおりです:
ユーザー センターは各人 (A) の招待リンクを生成し、招待者 (B) がクリックして登録すると、B の登録フィールドの後に A の ID がマークとして挿入されます。
現在は、各人が招待した友達リストをカウントできますが、将来的には次のような問題が発生します。
招待者 B が初めて注文する場合、ポイント特典の 10% が付与されます。初めての注文でない場合は特典は付与されません (これは私なりの愚かな考えですが、各ユーザーが注文すると、まず報酬が与えられます。上位のユーザーAがいるかどうかを判断します。いない場合は、直接注文します。上位のユーザーAがいる場合は、上位のユーザーAがいるかどうかを再度判断します。初めて注文し、上司にポイントを追加し、同時にユーザー B に注文を出します)
次のようにできると思います:
友達関係: 別のテーブルを作成できます
好友关系表
,里面存两个字段uid
(用户ID),contact_uid
(関連付けられた友達ID)初めて注文する場合でも、友達に勧めることでポイントを追加する場合も: 注文したことがあるかどうかに関係なく、ユーザー関連テーブルにフィールドを追加できます (前述)。デフォルトは 0 です。つまり、注文をしていません。注文するたびに、このフィールドが最初に照会されます。それが
1
の場合は、通常の注文ロジックに従います。0 の場合は、注文が一度も行われていないことを意味します。ユーザーが推奨者を持っているかどうか、推奨者にポイントを追加するなど、使用するロジックが実行されます。 処理中パフォーマンスに影響を与えるため、これを行わないでください。
統計ポイントは毎朝計算されます。
このテーブルには ID、B の ID、C の ID、および buystate フィールドの値は 1 または 0 です。0 は最初の購入ではないことを意味し、1 は最初の購入であることを意味します。
フィールドを直接追加します。以前に注文したことがあるかどうかに関係なく、デフォルトは 0 です。いずれにしても、注文時にユーザーの情報が取得されます。ちなみに、0 に等しいかどうかを判断することができます。最初の注文。ポイントとしては、パフォーマンスが心配な場合はredisに保存し、一定時間にデータベースを変更することも考えられます。
その考えは大丈夫だと思います
一つ言っておきますが、ポイント付与は注文時ではなく、注文完了後となります。
ユーザーテーブルにフィールドを追加して、過去の完了注文数を示すだけで、後で需要が変化した場合でも、最初の N 回分のポイントを簡単に返すことができます。また、通常、注文または注文を完了するプロセスでは、ユーザー テーブルへのクエリが必要ですが、これは複雑ではありません。