1

私は Web ショップを構築しようとしていますが、ユーザー情報を追跡するソリューションを考え出す必要があります。これに基づいて、ユーザーが好む可能性のある製品を提案し、個々のユーザー プロファイル (ユーザーの好み) を構築します。

アルゴリズムで追跡/使用される情報には、次のものを含める必要があると思いました。

  • 過去の注文
  • ウィッシュリスト/ブックマーク/お気に入り...
  • 入力した検索語
  • 表示された製品 (ここでは、ユーザーがサイトを閉じる/すぐに戻るか、他の写真を見る/下にスクロールする (ビューポート) などを意味する「ドロップオフ」の見積もりも追跡して検討します)

製品には、色、タグなどのさまざまな属性だけでなく、カテゴリが割り当てられます。テーブルは、、などproductと関係があります。colorcategory

商品
ID_商品
価格
タイムスタンプ_追加

色
id_color
...

product_color
id_product_color
id_product
id_color

質問は次のとおりです。

1) 閲覧した製品などを追跡するデータベースをどのように構築しますか? このようにする必要がありますか?:

product_viewed
id_product_viewed
id_product
id_user
タイムスタンプ

2) たとえば、ユーザーが購入した商品の色、ウィッシュ リストに追加した商品、ブックマークした商品、閲覧した商品の色に基づいて、ユーザーの好きな色のトップ 3 を計算したい場合: パフォーマンスの観点から、どの製品を推奨する必要があるかを計算できますか?毎回データベースにクエリを実行するときにこれに？それとも、ユーザー プロファイルを時々更新し、追跡データに基づいてその時点で既に計算された好きな色のみを保存し、保存された計算データを使用して、この情報に一致する製品を見つけますか?

フェイスブック、アマゾン、ピンタレストなどの大規模サイトはどのようにこれを行っているのでしょうか? pinterest では、以前にクリックした項目に基づいて、好みの項目の提案が表示されます。彼らはこれをどのように処理しますか？

4

2 に答える 2

1

はい、product_viewed のスキーマは問題ありません。

彼らの 3 つの好きな色については、次のテストされていないコードを試してください。

select c.name, count(*) as rank
from product_viewed pv
JOIN product_color pc on pc.id_product = pv.id_product
JOIN color c on pc.id_color = c.id_color
where pv.id_user = 1
group by c.name
order by rank desc
limit 3

テーブルの結合に使用される ID のインデックスと、表示されるアイテム数の合理的な制限を考えると、これはまともなパフォーマンスを発揮するはずです。将来的には、最新の 100 製品などだけを見て、それが永遠に成長しないようにすることもできます。（または、あなたが示唆するように、キャッシング）。

これには魔法はありませんので、おそらく他のサイトが行っていることと似ています。

于 2012-09-18T23:52:32.300 に答える
0

あなたが書いたようなテーブルでそれを行うのは良い方法です。Facebookなどもそうしています。

しかし、効率を高めるために、いわゆる B ツリーを使用します。

于 2012-09-18T22:55:02.113 に答える