こんにちは、私の仲間のプログラマーの皆さん、
私はゼロからオンライン ショップを設計およびプログラミングしています。フロントエンド経由で受け取った「注文」を管理するモジュールがあります。
特定の瞬間に注文で何が起こっているかを知るために、ステータスが必要です。ステータスは次のとおりです。
私の質問は単純なものですが、ストアのデザインを決定することが非常に重要であり、次のとおりです。このステータスを保存するにはどうしますか: Orders テーブルに列を作成しますか、それとも単にステータスを「計算」しますか?支払いが受領されたか、注文ごとに出荷されたかに応じて、各注文の （is_cancelled列を除いて）
この種の問題をモデル化するための最良のアプローチは何でしょうか?
PD: 将来的には、これらのステータスを構成可能にして、同じソフトウェアを使用している他のクライアントを購入できるようにしたいとさえ思っています..
Orders理論的根拠は、複数または（実装に応じて）にOrders関連付けることができる場合、のステータスは保留中または完了したものと絶対的な関係を持たないため、直接計算できないということです。PaymentsInvoicesOrder Payment
支払いが受け取られていなくても、支払い済みまたは完了Orderとしてマークされる可能性があります。注文は正確にそれを表します：顧客への予定された出荷。実際の収入を表すものであってはなりません。実際の収入は、テーブルのドメインです。 Payments
正確な実装はワークフローによって異なります。私は以前に「完了した」注文を支払いの「代替」として会計処理しましたが、面倒になります。特に、プロモーションを実行したり、在庫を譲渡したりして、失われた在庫を考慮しなければならず、収入がない場合は特にそうです。会計地獄へようこそ。
注文に対してaPaymentを受信すると、ビジネスロジックが注文のステータスを調整するかどうかを決定する必要があります。注文が保留中で、受け取った支払いの合計が注文額以上になる場合は、が支払いOrder済みとしてマークされ、発送の準備ができていることを示します。
要約すると、完了Paymentsは収入を表し、完了Ordersは出荷および/または在庫変更を表します。
計算できるなら計算すればいい。そうしないと、データが冗長になり、不整合が生じる危険性があります。
パフォーマンス上の理由やクエリを簡単にするためにステータス列を追加できないと言っているわけではありませんが、それなしで始めて、信頼できるデータがそのまま維持されるようにしてください。個人的には、パフォーマンスが十分でないことを証明できない限り、クエリで計算するアプローチを使い続けることを好みます。
注文の各行に対してステータスを保存します。誰かが 2 つのものを注文し、そのうちの 1 つをキャンセルした場合を考慮する必要があります。
orders テーブルに status_id 列があり、次に ID とステータスの説明（「保留中、保留中」など）を含む別の orders_status テーブルがあります。
注文が完了すると、支払いモジュールはステータスを保留に設定します。
私は他に2つの分野を持っている傾向があります: -
Boolean ispaymentcompleted は、注文が実際に支払い条件で完了し、処理する準備ができているかどうかを示します。支払いが成功した後に注文の詳細のみを保存する場合、これは問題ではありません。
次に、管理システムで新しい注文を強調表示し、処理が必要な新しい注文をすばやく判断するための isneworder ブール フィールドを用意します。
PS。注文の注文ステータスを追跡する必要があります。その場で計算すると、柔軟性が低下します。これは、私が遭遇したすべての e コマース システムの標準的な実装です。