注文ステータス タイプ / 配送ステータス タイプ / 支払いステータス タイプの異なるテーブルを持つ、いくつかの異なるショッピング カート スキーマを見てきました。
私は自分のプロジェクトで初めてこれを正しくしたいと思っており、最善のアプローチは何かと考えていました。
もちろん、重要なことは、使用する列の数に関係なく、相互に排他的なものを表す必要があるということです。
私は次のようなことを考えています：
OrderStatus - 概要ステータス PaymentStatus - 支払い済み/未払い/一部支払い済み/エラー ShippingStatus - 未発送/一部発送済み/発送済み/手渡し
これを分解する最善の方法は何ですか?全体的な「人間が読める」ステータスと、プロセスの独立した各部分の個々のステータスを表す「要約」ステータスも必要ですか?
「相互に排他的」なさまざまな状態がある場合は常に、その列に複数の可能な値を持つ単一の列があることを意味します。ほとんどの場合、これらの値は制限する必要があります。これを行うための最良かつ最も一般的な方法の1つは、「ディクショナリ」または「ルックアップ」テーブルへの外部キーを使用することです。したがって、最も基本的には、次のようなものがあります。
OrderStatusの値は次のようになります：* 1、 "Paid" * 2、 "Unpaid" * 3、 "Shipped" * 4、 "Unshipped"
重要な部分は、どのステータスが他のステータスと実際に相互に排他的であるかを判断することです。たとえば、上記の例の行は、「有料」と「出荷済み」の両方の順序になる可能性があるため、おそらくあまり良くありません。その場合は、OrderStatusをPaymentStatusとShippingStatusに分割することができます（あなたがほのめかしたように）。
これらの行を分割するかどうかの決定は、実際にはあなたとあなたの特定のニーズ次第です。ただし、何を決定する場合でも、ある時点で変更する必要があると想定してください。通常、変更されないアプリケーション/データベースは、使用されないために放棄された障害のあるアプリケーション/データベースのみです。「最初に正しく理解する」ことは立派な目標であり、事前に調査を行うことは保証されていますが、ほぼ確実にそれを達成することはできません。代わりに、アプリケーション全体を壊すことなくその一部を作り直すことができるように、デザイン/コードの残りの部分を柔軟で変更可能にすることに努力を費やしてください。
これは、カート自体の完全な機能に大きく依存します。SDLC に従うことをお勧めします。これにより、どの機能を開始する必要があるかをよりよく理解でき、データベースに格納する必要があるデータ (テーブル/フィールド) をより明確に把握できます。
これを開始するためのリンクを次に示します。
http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle
これを開始すると、通常、進行するにつれて必要になるフィールドと値を決定できます。
データベースに格納する必要があるデータを決定するポイントに到達したら、データベースの正規化ガイドラインを使用して、テーブルの構造化を支援できます。
http://en.wikipedia.org/wiki/Database_normalization
それが役立つことを願っています!