場景分析說明：
買家可以在張三家買茄子，李四家買蘿蔔，王五家買白菜，趙六家買豬肉等
那麼買家就應該有個訂單主表，我們稱為訂單表，同時還有 上面所說的具體的訂單明細表，清楚的檢視自己買了什麼菜，多少元一斤，買了多少斤等。
1. 訂單表的設計：
補充說明：交易狀態：存在下了單子沒付款，付款了沒結算等狀態。
付款狀態：存在未付款，已經付款。線下付款。（線下付款是這樣的場景，有些客戶對平台不熟悉，剛加入抱著試試的態度，所以他們選擇線下付款）
besttime:收貨人的最佳收貨時間，這個有些客戶說早上10點送過來，有些是說早上8點送過來。不同的客戶，送貨的時間是不一樣的。
訂單金額：存在這個下單的總金額
付款金額：就是最終這個訂單，使用者支付的費用。（存在這個場景，買家買了菜以後他不要菜了，需要退錢，然後退錢就退到買家餘額裡面，下次下單的時候就減少掉）
最終金額：就是最終計算完成後的金額。
這裡面的繞點就是業務方面，一般的情況生鮮生意方面都會存在多退少補的一種情況，所以出現了使用者餘額方面的事情。
2. 訂單明細表的設計：
補充說明： 1.在主訂單下面可以檢視清楚自己的訂單明細，也就是今天究竟買了那些菜，分別多少元一斤，我買了多少斤，最終多少錢等等具體情況
2. 還包括配送費用，以及對應的賣家是否備貨完成，我們去取貨等等，
3. 對於沒有備貨的商家，我們是可以用簡訊或者人為干預的
4. 對某個具體的配送師傅而言，我們也可以進行精細化的乙個管理。
最終還是有乙個問題，就是客戶在下單兩個小時內，我們是允許取消某乙個訂單的，這個也屬於人之常情，比如菜搞錯了，他可以取消某乙個訂單項，
但是不存在 取消整個訂單的情況，如果有，需要我們的客服從後台管理系統裡面進行人工干預。
相關實際運營如下：
電商平台 使用者表的設計
說明 由於該系統屬於b2b平台，不設計到b2c的架構。角色分析 買家與賣家.由於買家與賣家所填寫的資料都不一樣，需要建立兩站表進行維護，比如 buyer,seller.這樣進行資料庫的解耦，任何一方的變動都互不影響，但是我想集中式管理，以及一些業務個性化要求，我就增加了乙個users表。表結構如下 ...
電商平台 訂單抽成模組的設計與架構
說明 訂單抽成指的是向賣家收取相應的資訊服務費.目前市場上有兩種抽成方式，一種是按照總額的抽成比率，另外一種是按照訂單明細的抽成比率 由於生鮮電商的垂直領域的特殊性質，總額抽成不切合實際，所以按照訂單的明細抽成。1.訂單抽成，是按照乙個區的維度，以及菜品的二級分類類抽點的。舉例說明 比如武漢光谷區，...
電商平台訂單號生成策略
訂單是整個電子商務的核心。整個電子商務的流程也是圍繞訂單的狀態執行的。這篇部落格主要向大家介紹訂單號的生成方式。現在大型電商 大多都有好幾種下單途徑。比如 通過web 下單，通過打 到呼叫中心下單 callcenter 使用手機wap下單。如果只採用單資料庫來儲存訂單資訊的話，其隨著訂單量的增加，單...