クラスメートの Wu Lei がショッピング カートに関するアイデアをいくつか見たところです。私はたまたま電子商取引のこの側面に精通しているので、同僚に少しでも役立つことを願って飛びつきました。当初は以下に返信したかったのですが、書くのに時間がかかることが判明したので、将来的には自分で見つけるのが簡単になるかもしれません。 笑。ショッピングカート内のデータはデータベースに保存されますか?
特に、実際のソフトウェア エンジニアが実際のプロジェクトでこの問題についてどのように考えているかを知りたいと思っています。 Google で検索した後、庭のネチズンからの記事を見つけました。ショッピング カートはデータを一時的に保存するためのモジュールであるべきで、彼はそれを Session オブジェクトに保存しました。このネットユーザーの言ったことは理にかなっていますが、私はこのアプローチが好きではありません。全員がセッション オブジェクトに保存し、何千人ものユーザーが一緒に買い物をすると、ASP.NET サーバーに大きな負荷がかかることは間違いありません。おそらく国内のウェブサイトの方が優れているかもしれませんが、Amazon のようなウェブサイトではどうすればよいでしょうか? Joyo の Web サイトである Amazon China Web サイトは、セッション オブジェクトにそれを保存しません。これは、今回ショッピング カートに入れた製品の注文を送信しなかった場合、これらの製品はログイン後もショッピング カートに残っているためです。次回に。そこで、彼らはショッピングカートのデータをデータベースに入れているのではないかと思いました。
返信: ショッピング カートをセッションに保存する機能は、大学のコース設計や、誰も気に留めない一部のインターンシップ プロジェクトでのみ存在しているようです。実際、ほとんどすべての電子商取引 Web サイトでは、ショッピング カートのデータがデータベースに保存されています。ここでは、いくつかの説明と設計上の考慮事項を示します。
1. セッションは大量のデータを保存するのには適していません。ユーザーが多い場合、サーバーのパフォーマンスに影響が出るのは避けられません。
2. セッションが誤って失われる、またはユーザーが誤ってブラウザを閉じると、ショッピング カート内のすべてのアイテムが失われ、ユーザー エクスペリエンスが非常に悪くなるという問題があります。
3. 上記項目のセッション問題はCookieにより解決できますが、Cookieの長さ制限、Cookie使用時の通信オーバーヘッド、セキュリティ上の観点から、ショッピングカートにはCookieは適していません。
4. ユーザー エクスペリエンスが向上するのは、ユーザーがログインしているかどうかに関係なく、ショッピング カートのステータスを一定期間内に記録できることです。これには、データベース内のショッピング カートがユーザーに関連付けられていないことが必要です。
5. ショッピングカートに入れた商品は通常、購入意思のある商品ですが、必ずしも実際の注文になるとは限りません。このとき、このデータの保持はデータマイニングやビジネス分析において重要な役割を果たします。
質問: 2. 同時実行性について?
実は、私が独自の模擬 Web サイトを開発していたときに、次の質問を考えたことがあることがわかりました。「顧客が Web サイトのショッピング カートに本を入れた場合、その冊数は在庫から差し引かれるべきでしょうか?」それが私がやったことです。この時点で他のユーザーに誤った在庫数量が表示されないように、ショッピング カート内の該当する本の数量をデータベースから差し引きます (差し引かれなければ、他のユーザーが購入できます。例:在庫は 10 です。この本は、顧客 A がショッピング カートに 10 部入れ、顧客 B もショッピング カートに 10 部入れます。すると、誰がこの本を買うかという競合が発生します)。ただし、その結果、顧客がショッピング カートを更新するたびにデータベースとの通信が発生し、データ サーバーの負荷が増加します。 Amazon.cn はこの点であまりうまくいっていません。数日前、「オペレーティング システムの徹底理解」という書籍を購入したときに、注文したにもかかわらず通知が届くという問題に遭遇したと思います。翌日には在庫がなくなったということです。この事件は確かに Amazon.cn の信頼性に大きな影響を与えましたが、現在そのシステムがこの問題を解決しているかどうかはわかりませんが、「オペレーティング システムの徹底理解」という本の常陽価格は以前のものではありません。 。専門家がこの問題をどのように解決したかはわかりません。あなたの成功体験をコメントに書き込んでください。
回答: まず、データベース サーバーの負荷について考えます。ページにアクセスするたびにデータベースに何回アクセスする必要があるかを考えてから、1 回の追加操作で何回のやり取りが必要かを考えてください。ショッピング カート (アクセス数は主に Web サイトの使いやすさに依存します)。これは別のトピックです)。ここでデザインを変更すると、データベースへの負担が軽減される可能性がありますが、ボトルネックにはならないと Ding Xue 氏は考えています。ここではあまり注意を払う必要はありません。
現在、ショッピング カート内の商品は在庫からすぐには減らされないのが一般的です。これは主に、誰かがショッピング カートを介して商品を悪意的に占有することを防ぐためです。また、ほとんどの場合、冗長性が与えられます。ショッピング カート内の商品は在庫から差し引かれません。これは、ショッピング カートが売上に影響を与えないようにしなければなりません。通常、在庫は注文が正常に送信されたときに差し引かれます。つまり、ユーザーが注文を送信したときに、ユーザーに在庫がないことを再度通知する機会があるため、注文時に在庫を差し引く必要はありません。ショッピングカート。成功した注文の場合、ユーザーが送信したすべての注文が成功した注文とみなされるわけではありません。このプログラムは作成が困難ですが、以前のデータ分析、ユーザーの行動、ユーザーの評判などに基づいています。データは、注文の審査を数分以内に自動的に完了するシステムから取得されます。これにより、ほとんどの偽注文を排除できるため、手動審査に移行する必要がある場合があります。自動審査システムによる。
コンサートチケットなど一部の特別な商品については、オンラインで座席を選択できる場合があり、現在はショッピングカートに入れてから座席を予約するのが一般的です。ショッピングカートに入れた直後は自動解除されますが、一定時間（10分程度）以内に実際の注文にならなかった場合は自動的に解除されますが、悪質な座席占有を完全に排除することはできませんが、ほとんどの問題は解決できます。現在、発券業界でのオンライン座席指定注文の成功の判断基準は、支払いが成功したかどうかです。つまり、支払いがなければ 10 日間しか滞在できません。分。
質問: 3. 注文および注文内容とショッピングカートの関係
この問題は、この種の Web サイトにとって常に大きな問題だったのではないかと思います。 2 日前、CSTP のチェン先生がこの質問について電話でインタビューしてくれました。その時はとても緊張していて、質問に対する私の答えはあまり明確ではありませんでした。実際、この問題は単純に考えるのは難しくありません。注文と詳細という 2 つのテーブルがあり、注文テーブルの各列は詳細テーブルの対応する列を指します。外部キーは、注文テーブル内の注文番号です。
回答: この質問は比較的単純です。その 1 つは、ショッピング カートにそれを入れてステータスを付けることです。この状態では、注文を変更することができ、ショッピング カートは注文システムに統合されます。ユーザーのログイン状態と非ログイン状態の処理に注意してください); 2 つ目は、注文が最終的に送信されると、ショッピング カート内の情報が注文と注文の詳細テーブルにコピーされることです。後者の方が一般的に使用され、具体的な選択は業界や製品の属性によって異なります。
質問: 4. 詳細リストの注文番号を生成するにはどうすればよいですか?
この質問は質問 3 から引き継がれています。この問題の解決方法がまだわかりません。解決策は 2 つあり、1 つはトリガーを使用する方法、もう 1 つはプログラミングです。前者は、顧客がショッピングカートに商品を入れるたびに詳細を追加し、購入を確認した後に注文を生成し、詳細テーブルの購入ステータスを変更してトリガーをトリガーして注文番号を生成します（もちろん、この注文番号はトリガーでのプログラミングは、シリアル番号を自動的に生成するために注文テーブルに注文番号の列を設定することもできます)。後者は注文番号を判断し、それに 1 を加算して新しい注文番号を生成します。しかし、私はこれら 2 つの解決策が非常に悪いと常々感じているので、商用 Web サイトで注文番号がどのように扱われるのか知りたいと思っています。
返信: まず、個人的には、トリガー ソリューションはお勧めできません。理由は説明しません。そうでないと大変なことになります。ここにも 2 つの方法があります。1 つは、注文を生成するときに、まず注文番号を取得し、次に注文詳細テーブルを更新する方法です。ビジネス ルールに従った注文番号。注文番号がわかったら、最初に注文レコードまたは詳細レコードを生成できますが、最終的に詳細レコードに注文レコードが必要であることを確認する必要があります。奇妙な詳細がたくさんあります。後者の方法には 2 つの方法があり、1 つはデータベースによって生成され、一般的には一時テーブルが使用されます。もう 1 つは、シリアル番号をすべてのビジネスで共通に使用できることです。番号はプログラムによって生成されます。GUID はプログラムの生成時に使用できますが、より良い方法は、順序時間に識別値を加えたものを使用することです。粒度の大きさはボリュームに基づいて決定されます。識別部分には順番に番号が付けられます。これは、他人が業務量を大雑把にカウントしないようにするためにも考慮する必要があります（汗～～～これもまた問題です。）状況によりますが、注文番号の生成についてはまた後日書きますので、情報は十分にあると思います。