2

注文を作成するシステムがあり、その注文は自宅の口座に請求したり、代金引換 (COD) で送信したり、クレジット カードに請求したりできます。次のテーブルを作成しました。

ORDERS
order_idbillingoption_id
_

BILLINGOPTIONS課金オプション
_id

請求データ用に次のテーブルをどのように作成すればよいかわかりません。請求オプションのタイプ (つまり、代金引換、クレジット カード、ハウス アカウント) ごとに個別のテーブルを作成する必要がありますか? 次に、請求データのレコードを参照する別の外部キー列を Orders テーブルに作成しますか?

4

2 に答える 2

9

いずれかの方法で行うことができます:billingoptionsすべての型を包含するフィールドを持つ大きなクラクション テーブル、特定の型に適用されないフィールドの NULL、または親billingoptionsテーブルの「スター オフ」の赤ちゃんテーブルの束。 . どちらにも長所と短所があります。

大きな警笛を鳴らすテーブルのために、

  • すべてのデータが 1 つのテーブルで簡単に参照できるのは素晴らしいことです。
  • 外部キーの依存関係を追跡し、更新または挿入を実行すると効率的です。
  • ただし、将来的に新しい請求オプションを追加するためにテーブル構造を変更する必要があり、データの無効な組み合わせが保存される可能性があります (たとえば、クレジット カードの種類と COD フラグの両方が同じレコードに設定されているなど)。

小さなベビーテーブルの場合、

  • データが分割され、プログラムのオブジェクト構造を厳密に反映しているのは素晴らしいことです。
  • 他の支払いオプションに影響を与えることを心配することなく、新しい支払いオプションを追加したり、既存のものを変更したりできるのは素晴らしいことです.
  • 関係は非常に明確です。外部キーは承認とリンクする必要があるため、誤ってデポジットを別のデポジットにリンクすることはできません。
  • しかし、多くの JOIN を必要とする多くのテーブルを設計に導入することになり、ナビゲートするのが面倒になり、挿入と更新に関しては効率的ではなくなります。

仕事では、小さなベビーテーブルを使用することになりました。次のようになります。

テーブルオーダー:
--> OrderId PK
--> (多くの他のフィールド)

テーブル ペイメント:
--> PaymentId PK
--> OrderId (FK) [注文ごとに複数の支払いがある場合があります]
--> PaymentType [制限されたフィールドには次のような値が含まれます
       「PAYPAL」または「CREDIT」、これを使用してどちらかを知る
       追加を含むことができるルックアップする赤ちゃんテーブル
       情報]

テーブル ペイメントPayPal:
--> PaymentPayPalId PK
--> PaymentId FK は Table Payments を指します
--> 取引番号
--> (その他の PayPal 固有のフィールド)

テーブル ペイメントチェック:
--> PaymentCheckId PK
--> PaymentId FK は Table Payments を指します
--> ルーティング番号
--> (その他の e-check 固有のフィールド)

+残りの支払いタイプのその他の表....

すべての支払いタイプは、次の 3 つのトランザクション関連テーブルを共有します。

表 PaymentApprovals:
--> PaymentApprovalId PK
--> PaymentId FK は Table Payments を指します
--> ステータス [「成功」、「失敗」、「取り消し」などを意味するフラグ]
--> ProcessorMessage ['(M) CVV2 Matched' など、サービスが返信したもの]
--> 金額
--> (その他の行政分野)

表 PaymentDeposits:
--> PaymentDepositId PK
--> PaymentApprovalId FK はテーブル PaymentApprovals を指します
--> ステータス
--> ProcessorMessage
--> 金額
--> (その他の行政分野)

表 PaymentRefunds:
--> PaymentRefundId PK
--> PaymentDepositId FK はテーブル PaymentDeposits を指します
--> ステータス
--> ProcessorMessage
--> 金額
--> (その他の行政分野)

すべての支払い方法 (クレジット カード、PayPal、Google チェックアウト、小切手、現金、ストア クレジット、マネー オーダー) は、この承認 --> デポジット --> 払い戻しのメタファーに適合するように抽象化されており、UI は同じメソッドを呼び出します。IPaymentと、IPaymentProcessor実装が異なるインターフェイス ( CybersourcePaymentProcessor、PayPalPaymentProcessorなど)。この抽象化は、過去 1 年半にわたってこれらの異なるメソッド間でかなりうまく機能してきましたが、GUI がユーザーに対して異なる言葉遣いを表示することがあります (たとえば、「承認」と「請求」ではなく「承認」と「請求」と表示されます)。クレジットカード決済の「入金」画面、現金入力画面で決裁・入金が一挙に行えます。）

それが理にかなっていることを願っています。実際には支払い情報を保存していないように思えますが、これらがどこに行き着くかを考えると役に立ちます。

于 2008-11-23T05:10:42.237 に答える
8

物事に集中する。実際のもの。まず、物事を簡単に、直接的に、自然言語で説明するようにしてください。

次に、設計のガイダンスを求めるときに、定義を提供できます。場合によっては、定義を書くという行為が設計を結晶化させます。

注文は物です。注文の属性は何ですか? 顧客、製品、支払い/請求オプション。

請求オプションは（ほとんど）ものです。どうやら、それらを定義して識別することができます。(できるかどうかわかりません。あなたの質問から、できるように見えます。しかし、1 文の要約がなければ、Billion Options で何が起こっているのかわかりません。

「課金データ」とは？これはどのようなものですか？どのような属性 (またはプロパティ) を持っていますか?

「請求データ」は注文とどのように関連していますか? 請求オプションとの関係は?

それぞれの定義で質問を自由に更新してください。

于 2008-11-23T02:00:16.973 に答える