3

セッションを使用して、ユーザーの希望リストにアイテムを保存しています。

ウィッシュリストは、一意のアイテムIDの単純な配列として保存されます。平均的なユーザーはウィッシュリストに約40個のアイテムを保存しますが、ユーザーがウィッシュリストに数百個ものアイテムを追加したい場合もあります。

後でウィッシュリストに再度アクセスしたり、ウィッシュリストを自分のリストの開始点として使用できる他のユーザーと共有したりできるように、一意のURLを生成したいと思います。

私はユーザーからデータを収集していません。また、ユーザーはウィッシュリストデータをリンクするためのアカウントを持っていません。

私が検討しているこれに対処する2つの方法は次のとおりです。

URLエンコードされたシリアル化された文字列またはbase64エンコードされた文字列のいずれかとして、URLの最後にハッシュとしてデータを保存します。ウィッシュリストを保存する必要がなく、ユーザーが既存のリストを変更するための柔軟性が高いため、これは好ましいようですが、ウィッシュリスト内のアイテムの数が増え、URLの長さがそれを超えると、これは機能しなくなると思われます。実行可能な文字数。

また

一意のIDを使用してURLを生成し、ウィッシュリストをデータベースに保存します。これで私が目にする問題は、ユーザーがURLを生成するたびに新しいエントリがデータベースに追加され、これらのエントリは1人のユーザーに関連付けられないため、毎回新しいエントリを生成する必要があることです。ユーザーがリストに変更を加えた時間。

これを処理するための別のより良いアプローチ、または上記の方法に関連する問題を管理する方法はありますか？

4

1 に答える 1

1

長期的には、データベースルートを使用することが最も柔軟なソリューションになると思います。データが適切にモデル化されている限り、ユーザーが選択を行うたびにレコードを追加/削除することは問題にはなりません。「選択」は、キーによって2つのものを参照するレコードのみを作成する必要があります。ユーザー、製品に加えて、おそらく数量と価格。

そうは言っても、私はこれに似たモデルでそれを行います：

  • 製品番号、 ...）
  • selection_set（id、name）
  • 選択（product_id、selection_set_id、数量、価格）
  • ウィッシュリスト（public_hash、selection_set_id）

ウィッシュリストはselection_setとは別のものです。これは、selection_setをショッピングカートや注文などの他の目的で再利用できるためです。

それが完了したら、public_hashをcookie / sessionに保存し、リンクするURLを指定するだけです。

それはあなたが考えていたシナリオでうまくいくでしょうか？または追加の制約はありますか？

代替ソリューション：

データベースは実行可能なソリューションだと思いますが、いくつかの選択肢が考えられます。

データの圧縮とエンコード：

ウィッシュリストアイテムID（またはある種の一意の識別子）のコンマ区切りリストを取得してから、base64_encode（gzinflate（$ list））を取得し、それをハッシュとして使用できます。次に、gzdeflate（base64_decode（$ hash））を使用してアイテムのリストを取得できます。ページが読み込まれるたびにこれを回避するために、セッション内で選択内容を保存し続け、リストが変更された場合にのみハッシュを再生成できます。

gzdeflate + base64は、最大で非常に大きなウィッシュリストを選択できるように、ハッシュを妥当な長さの範囲内に保つ必要があります。いくつかの単体テストを記述して、ハッシュ/リストが仮想的に取得できる時間を確認できます。

この方法は完全なハックのように感じます:-)

Redisを使用する：

redisサーバーをセットアップし、そこにウィッシュリストを保存できます。永続的で、スケーラブルで、高速で、簡単にアクセスできます。

于 2012-11-25T05:51:22.450 に答える