首先使用者瀏覽商品，將看中的商品加入到購物車，這裡應該有一張購物車表：購物車表（order_cart）
# 購物車表（order_cart）
-- -- --
skuid
spuid
使用者id
店鋪id
商品名稱
商品數量
商品**
狀態（下單之後對應商品就不應該顯示在購物車了）
# 訂單表(order_info)
----
訂單編號（如果對編號格式沒什麼要求，可使用雪花演算法idworker來生成）
itemcount （商品項數量，不是商品個數，比如手機*2，滑鼠*1，這裡應該是2）
使用者id
店鋪id
下單時間
支付時間
outtradeno 支付寶訂單號
配送方式
期望配送日期
商品總額
運費實際付款
訂單狀態（這裡的狀態可根據實際專案來定，可以定10,20,30..這樣如果中間缺少乙個狀態可以新增進去）
上面是訂單的基本資訊，接下來是訂單商品相關。
# 訂單商品表(order_product)
---
訂單編號
spuid
skuid
店鋪id
商品名稱
商品數量
商品**
下單完成，等著發貨，物流資訊不能少，接下來是物流表
# 物流表（order_logistics）
---
訂單標號
物流公司id
物流公司編號
快遞單號
發貨時間
收貨時間
# 物流跟蹤表（order_logistics_flow）
---
訂單標號
物流公司標號
快遞單號
remark（根據第三方介面返回來的結果資訊）
# 訂單發票（order_invoice）
---
發票型別
發票抬頭
發票內容
***碼
發票號碼
開票日期
校驗碼密碼區
服務名稱
規格型號
數量單價
金額合計
稅率稅額
銷售方名稱
銷售方納稅人識別號
銷售方位址**
銷售方開戶行及賬號
備註收入款人
開票人
# 支付記錄表（order_pay_history）
---訂單編號
支付方式
訂單總額
支付金額
pay_json（第三方支付平台引數資訊，可使用json方式儲存）
remark （備註）
spuid
skuid
使用者暱稱
點讚數
注意：如果一開始就想做分布式系統，建議把商品相關的表和訂單表放在同乙個資料庫中，一則是因為訂單業務需要查詢商品相關的資料，二則是因為放在一起做事務比較容易，不然需要做分布式事務，加大了開發 成本。前期專案規劃的時候這點需要考慮到訂單型別： 1）單商戶型別 2）多商戶型別
乙個使用者可以購買多個商家的多個商品
問題1：訂單怎麼分配？ 乙個訂單 多個訂單
問題2：支付怎麼實現？ 支付的錢分配給多個商家。
問題3：提交訂單後，此時訂單處於什麼狀態？ 待支付
問題4： 提交訂單，是否減庫存？ 有的系統是提交訂單減庫存，有的系統是支付減庫存。
提交訂單：很多不同的商品 + 運費 + 補運費+優惠券 訂單應該做乙個拆分，基於這樣的拆分方式，才可以支付退 款，退貨，優惠券的功能
金額拆分：
待付款（1）、
待發貨（2：已經付完畢）、
已發貨（3）、
已完成（4）、
已關閉（5）、
退款狀態（6）
關於生成訂單號的解決方案
關於生成訂單號的解決方案 電子商務及類電子商務的系統越來越多，我相信訂單號問題是這類系統中最常見不過的乙個問題了，但今天還是想談談。這幾天由於工作需要接手了另外一同事前期開發的乙個交易系統，原本使用的是uniqid 函式生成的。uniqid 是根據系統時間經過一定演算法得到的乙個結果，關於uniqi...
mysql 解決方案 Mysql解決方案
mysql解決方案 一 centos7安裝mysql5.7 wget rpm uvh mysql80 community release el7 3.noarch.rpm yum repolist all grep mysql 發現預設mysql8.0是預設安裝的，然而我們要安裝的是mysql5.7...
採購訂單模板 採購管理系統解決方案
混亂的採購管理是太多組織的一種生活方式，組織內採購方式的變化使更加混亂。潛伏這種威脅的主要原因是組織遵循的手動和紙張密集型採購實踐。使用採購管理系統，可有效執行採購到付款週期，同時執行適當的採購策略。獲得完整的支出可見性，基於規則的自動化流程，更好的 商關係管理並滿足您的採購目標。許多組織沒有有效的...