0

ユーザーがライセンスを購入する行為を処理する必要があるアプリを設計しています。私は認証部分には焦点を当てていませんが、プロセスのトランザクション部分のみに焦点を当てています
基本的に私はこれらのモデルを定義します:

1) ユーザー - ユーザーのデータを保持します
。 2) ライセンス - ライセンスのデータを保持します。ユーザーは複数のライセンスを購入できるため、ユーザーとは多対 1 の関係があり、トランザクションとは 1 対 1 の関係があります (1 つのライセンスは 1 つのトランザクションのみに関連して
います) 3) 支払い方法 - 支払い方法を保持するもの (基本的にはクレジット)カード）。これはユーザーと多すぎる関係を持っています
4) トランザクション - トランザクションのデータを保持し、ユーザーとの 1 対 1 の関係 (1 つのトランザクションは 1 人のユーザーのみによって行われます) と支払いとの 1 対 1 の関係を持ちます。メソッド (1 つのトランザクションが 1 つの支払い方法に関連付けられています)

これは正しいと思いますか？
ユーザーとライセンスの間に関係を追加することで冗長性を追加しています (これはトランザクションによってのみ接続できます) が、SQL でいくつかの JOINS を節約できると思います。

4

1 に答える 1

1

あらゆる種類の製品注文システムに同じスキーマを使用できます。

顧客関係者は、ベンダー関係者に 1 つ以上のカタログ アイテムの販売注文を出します。その1 つが、ソフトウェア ライセンスなどの販売契約である場合があります。

仕入先は、請求先住所で請求先 (顧客側と同じ場合もある)に 1 回以上請求(支払いを要求) します。請求先は、請求書が支払われるまで、その特定の請求書に対して1 回以上の支払いを行います。

支払いは、受注明細の出荷または配送と必ずしも一致しません。請求書が支払われる前または後に、販売注文品目を出荷できます。

販売注文アイテムは、出荷先住所(IP アドレスまたは電子メール アドレス) の出荷先に出荷され、うまくいけば配送され、その時点で収益が発生します。

これで始められるはずです：

PARTY
id
type {organization, individual, automated_agent}
name
...


ADDRESS
id 
type {email, web, facility, telephone}
...


SALES_ORDER
id
order_date
customer_id -> party
vendor_id -> party
bill_to_id -> party
bill_to_address_id -> address


CATALOG_ITEM
id
type {good, service, agreement}
...


SALES_ORDER_ITEM
id
sales_order_id -> sales_order
catalog_item_id -> catalog_item
ship_to_id -> party
ship_to_address_id -> address
price
quantity


PAYMENT_METHOD
id
name


# whether payment has a key to invoice depends on whether you allow cross-invoice payments and/or partial payments
PAYMENT
id
payment_date 
payer_id -> party
payee_id -> party
amount
method -> payment_method

省略:

shipment_request
shipment
delivery
invoice
invoice_payment
于 2013-02-04T20:37:47.477 に答える