私は注文システムを扱っており、まずなぜそれがそのように設計されたのかを理解しようとしています.
私が理解できないことの 1 つは、顧客が注文する前であってもOrder、潜在的な顧客に対してシステムが一意のレコードを作成する理由です。
そのため、注文が入り、購入したいものを選択すると、ボタンが表示される前に、潜在的なPlace your order顧客の注文レコードが既に保存されています。
この結果、私が気になっているのは、ユーザーが販売を確定するための最終ボタンをクリックしなかったために、システム内に何千もの放棄された注文が存在することです。Place your order
ユーザーが「注文する」をクリックした後にのみ注文レコードが生成されるべきではありませんか? なぜそうしないのですか？
あなたの言ったことから判断すると、アプリケーションは非常に便利な機能を提供します。ユーザーが選択したものはすべて記憶されているため、ユーザーはページを閉じて他のアウトレットをチェックし、もう少し考え、サイトに戻って保存された注文を確認できます。
また、データベースに 1 万行を追加すると 1 ペニーの費用がかかるため、心配する必要はありません。また、問題が発生した場合、たとえばユーザーが 1 か月間表示されない場合など、定期的にクリーンアップできます。
Francis、これには多くの理由があり、何よりもまず分析です。これを達成する方法は他にもありますが、(a) 注文が放棄されたか、(b) プロセスのどの時点であったかを知る良い方法です。 . ユーザーが2日後に戻ってきて「チェックアウト」できるようにするのにも適しています:)
システムは、個別の「バスケット」エンティティと「注文」エンティティを使用して、一般的な e コマースの方法で機能しますか? それとも、ユーザーが注文にアイテムを追加してからそれを確定するときに、注文エンティティを構築するだけで機能しますか?
後者のシナリオの場合、すでに述べたように、進行中の注文を保存する手段として説明した方法で機能する可能性があります。しかし、それが前者のシナリオ (別のバスケットを使用) である場合、それは少し奇妙であり、不必要に思えます。
通常、ゼロから設計された専用の e コマース システムでは、「バスケット」(進行中の作業) と「注文」(完成品) の概念が分離されています。しかし、時間の経過とともに進化した可能性があり、当初は e コマースを念頭に置いて設計されていなかった可能性がある多くのシステムを見つけることができます。そこでは、少し面倒で最適とは言えないプロセスが発生します。