HTTPセッションまたはデータベースアプローチ

ショッピングカートの設計に取り組んでおり、セッションまたはデータベースのいずれかにショッピングカートを保存する必要がありますが、どちらのアプローチが最適かはわかりません。

1. ユーザーはログインしておらず、カートに商品を追加していません（匿名ユーザー）
2. ユーザーがログインし、カートに製品を追加しています。

ユーザーがログインせずにWebショップにアクセスして製品を追加するだけでなく、チェックアウトプロセスに行かない可能性が高いため、最初のケースは私を混乱させます。

ただし、ショッピングカートを作成して保存するには、このユーザーのショッピングカートを作成する必要があります。2つのオプションがあります。

1. ユーザーが製品を追加するときに、データベースにカートを作成し、このカートをこのユーザーに関連付けます。ログインした瞬間に、このカートをログインしているユーザーに移動します。
2. ユーザーがログインしてデータベースにカートを作成し、ログインしたユーザーをこのカートにユーザーと関連付けた場合、カートを作成し、製品を追加してセッションに保存します。

データベースベースのカートシステムとセッションベースの両方に肯定的側面と否定的側面があることを知っていますが、次の点を考慮するためにどちらが最善のアプローチであるかはわかりません

1. 拡張性
2. 柔軟性
3. 拡張性
4. アプリケーションは速度に注意する必要があります

この側面に関する入力を探して、パスを決定します。

すべての訪問者が最初にサイトにアクセスしたときに一意のIDが割り当てられるソリューションを探します。それらが匿名であるか認証されているかは関係ありません。匿名ユーザーが登録するとき、一意のIDを保持します。

ショッピングカートをデータベースに保存します。ストレージは安価であり、ときどきカートのクエリを実行することはパフォーマンス上問題になりません。

どちらの方法にも長所と短所がありますが、私の考えでは、データベースストレージには2つの大きな利点があります。

1. 報告。データがセッションにある場合、放棄されたカート、コンバージョン率などについてレポートすることはできません。
2. セッションのタイムアウト。セッションが期限切れになったために夕食を食べに行き、カートが空になったのを見つけに戻ってきたらイライラするでしょう。小売業者もそれを好まないと思うでしょう。私たちは、ユーザーをあきらめて去るのではなく、購入するように促します。

質問は、クライアントの市場では必要のないセッションが必要だと仮定していることです。私はたまたま数百のeコマースWebサイトを運営しており、そのうちのいくつかは高いトラフィックを獲得しています。セッションが使用されないのは、ファームアウトされない限りスケーラブルではないため、セッションが遅くなるか、より多くのセットアップが必要になるためです。セッションはメモリを消費し、セッション状態のデータベースフェッチは非常に遅く、より多くの可動部分を必要とします。

代わりに、HTML5 sessionStorageを使用して、何度もプルする必要があるユーザー情報を永続化しますが、帯域幅を増やすために毎回Cookieをトリップする必要はありません。これはIE8 +であり、他のすべての最新のブラウザーとモバイルデバイスはこの技術と互換性があります。ただし、これは以前のように、フォールバックとしてCookieにカートを簡単に保存できます。ここに良いcookie-cartがあります：http : //simplecartjs.org/

ユーザーがサインインまたはログインするとき、タイムスタンプが焼き付けられた暗号化されたCookieを使用します。

また、必要に応じてApplicationCacheを使用する方向に移動します。これにより、リソースやカタログデータをプリフェッチできるため、Webトラフィックがさらに減少します。もちろん、製品が変更されたときなどにマニフェストを更新するように注意する必要があります。

セッションストレージとデータベースストレージは排他的であると想定しています。そうではありません。しかし、それらがそうであると仮定することから始めましょう。

セッションストレージの利点は3つあります。

1. データベースに明示的にデータを挿入する必要はありません。セッション変数を設定するだけで完了です。機能的にシンプルで低リスク。
2. コンテナ/フレームワークがあなたのためにそれをするので、ユーザー訪問とショッピングカートのライフサイクルを管理する必要はありません
3. 通常、古いアイドルセッションの自動クリーンアップは自動的に行われます。

セッションストレージの欠点：

1. レプリケーションを調査しない限り、セッションアフィニティ
2. レプリケーションを調査するか、ディスクへのセッション状態の手動永続性を調査しない限り、フェイルオーバーはありません。
3. すべてのセッションはメモリに保存する必要があります。レプリケーションを使用する場合、これは増幅されます。

データベースストレージの利点：

1. セッションアフィニティまたは状態のレプリケーションについて心配する必要はありません。すべてのリクエストをラウンドロビンできます。
2. アプリケーションのメモリオーバーヘッドが少ない。
3. 注文が完了すると、とにかくすべてがデータベースに格納されるため、データが既に存在するため、これにより完了が容易になります。

データベースストレージの欠点：

1. 放棄されたカート-一部の匿名ユーザーがショッピングカートにアイテムを追加して消えました。何らかの種類の有効期限プロセスがない限り、そのデータは永久に存在し続けます。
2. ユーザーを追跡し、特定の要求に対して、これが既存または新しいブラウジングセッションを表しているかどうかを把握する方法を考え出す必要があります。（はい、Cookieを使用すればおそらく簡単ですが、2人のユーザーが同じIDにならないようにするにはどうすればよいでしょうか？）
3. より多くのコード

使用しているプラ​​ットフォームについては言及しませんでした。私は、リクエスト/レスポンスサイクルの存続期間中にのみセッションデータがメモリに存在し、データベースからロードしてデータベースに保存するデータベースバックアップセッションを使用するアプローチを探します。これは過去に私に役立っています。

データベースバックアップセッションの利点：

1. サーバーアフィニティの必要はありません。
2. アプリサーバーのメモリで簡単
3. アイドル/放棄されたセッションデータは自動的にクリーンアップされます。
4. ユーザーの最初の訪問、繰り返しの訪問、セッション終了のライフサイクルはすべてあなたのために把握されます。
5. コーディングが簡単

データベースでバックアップされたセッションの欠点：

1. 構成-コンテナを調査する必要があります。PHP、Java EE（Tomcat、Jetty、JBossなど）、node.js + express.js、またはこれをサポートしていないもので、適切な構成を提供してください。
2. 要求ごとに2つのデータベース操作を追加するため、これを負荷テストする必要がある場合があります。

第三の可能性があり、誰かが以前に触れました。セッションの使用を完全にスキップし、すべてをCookieまたはHTMLローカルストレージに埋め込むことにより、クライアント側のストレージを使用できます。

その長所/短所は演習として残しますが、html5ストレージの場合、ブラウザーの互換性は慎重に検討する必要があるかもしれないというヒントを示します。

私はあなたのために事実を概説しました。うまくいけば、これがあなたの状況に合った正しい決定を下すのに役立つことを願っています。

あなたが言及した2つのユースケースを考えてみましょう

ユーザーはログインしておらず、カートに商品を追加していません（匿名ユーザー）

この場合、ユーザーのセッション中にユーザーに十分にサービスを提供するために、ユーザーのカート情報をセッションに確実に保存する必要があります。彼/彼女がログイン/アカウントの作成を決定した場合、次のユースケースに基づいてこれを処理できます。ログインしていない場合は、このゲストユーザーの情報をデータベースに入力する必要はありません。データベースはセッション中にゲストにサービスを提供するためだけに使用されたためです。このデータはステートレスベースで処理できます。つまり、セッションごとに状態が保存されるわけではありません。

ユーザーがログインし、カートに製品を追加しています。

この場合、上記と同じ方法で（古い学校のeコマースサイト）処理し、この情報をデータベースに追加してユーザーに関連付けることができます。これは主に、Amazon.comに似た「製品の閲覧履歴」、「推奨事項」などのステートフル（セッションごとに保存された状態）情報を提供するために使用されます。

考えるべきこと：

• データを保存する必要はありますか？
• はいの場合、ユーザーにより良いサービスを提供するために保存する最も重要なデータは何ですか？
• スケーラビリティ+データストレージ-多くのユーザーをサポートするために、データベース内の高速検索のためにカート情報をどのように保存しますか？

ユーザーがログインしていないときにセッションを開始します。ログインした場合でも、最初にセッションでカートを作成し、ユーザーがログアウトまたはセッションがタイムアウトしたときにのみカートをデータベースに保持します。

セッションで作成されるカートの数をチェックする必要があります。