資料庫訂單表設計

2021-09-09 07:00:35 字數 4542 閱讀 6077

訂單表 (order)

|-- 自動編號(order_id, 自增長主鍵)

|-- 訂單單號(order_no, 唯一值,供客戶查詢)

|-- 商店編號(shop_id, 商店表自動編號)

|-- 訂單狀態 (order_status,未付款,已付款,已發貨,已簽收,退貨申請,退貨中,已退貨,取消交易)

|-- 商品數量 (product_count, 商品專案數量,不是商品)

|-- 商品總價 (product_amount_total)

|-- 訂單金額 (order_amount_total,實際付款金額)

|-- 運費金額 (logistics_fee)

|-- 是否開箱驗貨 (is_unpacking_inspection)

|-- 是否開票(是否開具發票)

|-- 發票編號 (訂單發票表自動編號)

|-- 收貨位址編號 (address_id, 收貨位址表自動編號)

|-- 訂單物流編號 (orderlogistics_id, 訂單物流表自動編號)

|-- 訂單支付渠道 (pay_channel)

|-- 訂單支付單號 (out_trade_no/escrow_trade_no,第三方支付流水號)

|-- 建立時間 (下單時間)

|-- 付款時間

|-- 發貨時間

|-- 客戶編號 (user_id,使用者表自動編號)

|-- 客戶備註

|-- 訂單結算狀態 (order_settlement_status,貨到付款、分期付款會用到)

|-- 訂單結算時間 (order_settlement_time)

訂單發票表 (order_invoice)

|-- 自動編號 (invoice_id)

|-- 訂單編號 (order_id)

|-- 是否增值稅發票 (is_vat, 普通發票,增值發票)

|-- 發票抬頭名稱 (invoice_title)

|-- 發票抬頭內容 (invoice_content)

|-- 發票金額 (invoice_amount)

|-- 發票稅號 (invoice_tax_no)

|-- 開票稅金 (invoice_tax)

|-- 公司名稱[增值稅] (vat_company_name)

|-- 公司位址[增值稅] (vat_company_address)

|-- 聯絡**[增值稅] (vat_telphone)

|-- 開戶銀行[增值稅] (vat_bank_name)

|-- 銀行帳號[增值稅] (vat_bank_account)

|-- 開票時間 (created_time)

訂單物流表 (order_logistics)

訂單退貨表 (order_returns)

訂單商品詳情表 (order_detail)

|-- 自動編號

|-- 訂單編號

|-- 商品編號

|-- 商品名稱 (product_name, 商品可能刪除,所以這裡要記錄,不能直接讀商品表)

|-- 商品** (product_price, 商品可能刪除,所以這裡要記錄)

|-- 商品型號 (product_marque,前台展示給客戶)

|-- 商品條碼 (product_store_barcode, 商品倉庫條碼)

|-- 商品型號資訊 (product_mode_desc,記錄詳細商品型號,如顏色、規格、包裝等)

|-- 商品型號引數 (product_mode_params, json格式,記錄單位編號、顏色編號、規格編號等)

|-- 折扣比例 (discount_rate 打幾折)

|-- 折扣金額 (discount_amount)

|-- 購買數量 (number)

|-- 小計金額 (subtotal)

|-- 商品是否有效 (is_product_exists)

|-- 客戶商品備註 (remark)

設計說明:商品可能被修改、刪除等,因此這裡要記錄下單時使用者關注的商品交易摘要資訊,如**、數量、型號、型號引數等。這樣就算後來商品被刪除了,使用者在檢視歷史訂單的時候也依然能看到商品的快照資訊。

收貨位址表 (delivery_address)

購物車表 (shoppingcart)

|-- 自動編號 (id)

|-- 使用者編號 (user_id)

|-- 商店編號 (shop_id)

|-- 商品編號 (product_id)

|-- 是否有效 (is_product_exists)

|-- 購買數量 (number)

|-- 建立時間 (created_time)

設計說明:商品**和小計金額是要通過實時關聯商品表來讀取和計算,因為商戶可能會更改商品**,或者商品已售罄,或者商品已下架等,因此這裡只需要記錄商品id就可以,商品**等要實時從商品表讀取。

******************************=用於**營銷的訂單模組的擴充套件設計***********************************===

訂單業務審核流程表 (order_auditbiz)

|-- 自動編號 (order_auditbiz_id)

|-- 訂單編號 (order_id)

|-- 訂單狀態 (0:未審核或發起交易;1:交易完成;20:核單通過;24:核單失敗;30:已發貨;未簽收;34:倉庫退回;40:座席取消;41:買家取消;42:逾期取消;43:訂單無效取消;50:客戶簽收;54:客戶拒簽;55:客戶退貨)

|-- 銷售員直接確認訂單(不需要訂單審核員確認,直接強制審核通過,如客戶退貨則銷售員必須承擔退貨運費) (is_seller_risk_confirm)

|-- 訂單退貨,銷售員是否承擔運費 (is_seller_punish

_logistics_fee)

|-- 銷售員是否提成 (is_seller_commission)

|-- 銷售員提成比例 (seller_commission_rate, 無提成則填0)

|-- 銷售員提成金額 (seller_commission_amount)

|-- 銷售員訂單備註(seller_remark,給訂單審核員看的備註)

|-- 訂單審核員訂單備註 (confirmer_remark,給倉管看的備註)

|-- 倉管備註(storekeeper_returnback_remark,倉管退給訂單審核員看的備註)

|-- 財務備註 (cashier_remark, 財務給銷售員看的備註)

|-- 銷售員使用者編號 (seller_uid)

|-- 訂單審核員使用者編號 (auditor_uid)

|-- 收款人使用者編號 (cashier_uid,收款人不一定是財務)

|-- 財務使用者編號 (accountant_uid, 財務人員使用者編號)

|-- 訂單** (order_source, 銷售下單,內部購買)

|-- 訂單審核員審核時間 (auditor_audited_time)

|-- 倉管員審核時間 (storekeeper_audited_time)

|-- 財務審核時間 (accountant_audited_time)

訂單提成表 (order_commission)

|-- 自動編號 (order_commission_id)

|-- 訂單編號 (order_id)

|-- 銷售員使用者編號 (seller_uid)

|-- 提成金額 (commission_amount)

|-- 結算狀態 (settlement_status)

|-- 結算時間 (settlement_time)

|-- 財務人員使用者編號 (cashier_uid)

訂單排程表 (order_dispatch)

|-- 自動編號

|-- 訂單編號

|-- 被排程的營銷人員使用者編號 (from_seller_uid)

|-- 營銷人員使用者編號 (to_seller_uid)

|-- 排程原因 (dispatch_reason)

|-- 排程管理員 (diapatch_admin_uid)

|-- 排程日期 (created_time)

資料庫設計原則是:

1. 為提高讀的效能,盡可能把寫的操作拆分到另一張表,因為對錶的更新操作會導致鎖表,會降低資料表的讀取的效能。

2. 交易時一些關聯資訊可能在後來會被修改或刪除,如商品、收貨位址等,因此要在訂單中記錄交易時的商品資訊和收貨位址,一邊後來商品或收貨位址被刪除的時候,依然能在歷史訂單中看到快照資訊。

3. 不要怕拆分成很多表,讀的時候多張表關聯讀取,會比讀取一張字段非常多的資料量龐大的表效率高很多。

儲存訂單資料庫表

1.我是用powerdesigner設計的,分為兩個表,ordername為外來鍵,設定外來鍵時出了點小插曲,這裡不羅嗦了,如圖 2.樣品單類直接封裝這兩個表的資料 public class order public order string from,string to,string ordert...

資料庫訂單狀態

order info 表 剛下完訂單 order status 0 shipping status 0 pay status 0 取消order status 2 shipping status 0 pay status 0 確認order status 1 shipping status 0 pa...

資料庫表設計

在軟體的開發中,資料庫表的設計是十分基礎和重要的工作。資料庫表是軟體具體實現的基石,如果表設計的不合規範就會出現資料冗餘,跟業務脫節等問題,等出現問題後再做大的調整相應的依賴表的編碼測試等工作也會進行大的調整這樣就會造成極大的資源消耗。因此在專案一開始設計表的時候就要注意表設計的規範性問題。資料庫 ...