我正在設計一個應用程序，它處理用戶購買許可證的行爲。我不是專注於認證的一部分，但只在過程的交易方
基本上我會定義這些機型：如何設計一個數據庫/ Django模型的一個應用程序，必須處理購買許可證
1）用戶 - 保存用戶
2）授權的數據 - 其中包含許可證的數據。這將與用戶有多對一的關係，因爲用戶可以購買多個許可證，並且與交易有一對一的關係（一個許可證僅與一個交易有關）
3）付款方式 - 持有付款方式（基本上是信用卡）。這與用戶有很多的一種關係。4）交易 - 它保存交易的數據，並且與用戶有一對一的關係（一個交易只由一個用戶完成）和一對一的關係付款方式（一筆交易與一種付款方式有關）
您認爲這樣對嗎？
我通過添加用戶和許可證（只能通過事務連接）之間的關係來添加一些冗餘，但我認爲它可以在SQL中節省一些JOINS。
您可以使用相同的模式對於任何一種產品訂單系統的：
一個客戶方地方銷售訂單有供應商一方一個或多個目錄項，一其中可能是銷售協議，如軟件許可證。
廠商黨發票（從請求支付）的收單方（誰可能是一樣的客戶方）在帳單地址，一次或多次。開票方對該特定發票進行一項或多項付款，直至發票爲付款。
支付不一定與銷售訂單項目的裝運或交付一致。您可以在支付發票之前或之後發運銷售訂單項目。
銷售訂單項目運到艦在收貨地址（這可能是一個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
我就不會擔心保存在SQL連接。有了這樣的東西，我確實喜歡半複製數據。進入許可證或交易，我可能會彈出用戶的電子郵件地址，IP地址等等。理由是在某個時候用戶可能會更改電子郵件，如果您有任何訂單問題出現，您會需要參考銷售時的細節（與用戶的當前信息相比較） –