題目背景：
之前做電商運營，打算轉行做開發，參加了幾個面試，幾乎每家都會問到大資料量時的解決方案。暫時不討論問這個題目的合理性，既然有需求，那自己就加強吧。所以基於目前個人做的乙個系統，計畫向大資料量做擴充套件設計。
涉及的業務場景：
（1）市場中有多個賣家（seller），可檢視、處理包含該賣家商品的訂單（order）
（2）買家（user）可檢視跟蹤自己的訂單
訂單表設計方案及查詢時處理邏輯
方案1(初始方案)
（1） 原始訂單表按照買家id取模分表
（2） 新建買家與訂單的對映關係表（也會資料量很大，可再按orderid取模分表）
查詢處理邏輯：
1買家查詢自己所有的訂單：按照userid取模找到對應的訂單分表，取資料
2買家按照訂單號查詢訂單：根據orderid從買家訂單對映中獲得userid，然後仍然是按照userid取模找到對應的訂單分表
問題：這樣拆分後，與賣家有關的訂單就被拆在多張表中，賣家檢視自己的訂單時還是要掃瞄所有資料
方案2（修改方案1）
對原始訂單也按照賣家id取模分表，然後再建立賣家與訂單的對映關係
問題：該方案雖然能實現設定的業務邏輯，但訂單資料要儲存兩份，要維護兩個對映表
方案3（修改方案2）
學習了**的訂單系統設計，將訂單拆分為買家庫、賣家庫，訊息中介軟體進行訂單同步（類似於方案1、2的對買家、賣家分表麼），似乎是不關注訂單資料冗餘，但沒想明白如何按照訂單查詢，所以借鑑設計了方案3:
（1）按照userid取模分表
（2）按照sellerid取模分表
（3）按照orderid取模分表
相比方案1、2，少維護了一張表，但有兩份資料冗餘
電商平台 訂單表的設計
場景分析說明 買家可以在張三家買茄子，李四家買蘿蔔，王五家買白菜，趙六家買豬肉等 那麼買家就應該有個訂單主表，我們稱為訂單表，同時還有 上面所說的具體的訂單明細表，清楚的檢視自己買了什麼菜，多少元一斤，買了多少斤等。1.訂單表的設計 補充說明 交易狀態 存在下了單子沒付款，付款了沒結算等狀態。付款狀...
訂單系統訂單表設計方案
一年前，在上一家公司接手了乙個含有訂單系統的專案，業務並不複雜，但是當時令我比較困惑的是訂單表的設計。困惑的點主要是隨著訂單量增加，單錶的儲存能力將達到瓶頸，必然要採用分表的方案，那麼按照什麼維度拆分合適呢？分表之後帶來的最大的挑戰是訂單查詢。如果以使用者為中心，採用userid取模，可以很方便的處...
電商 支付 支付流水表與訂單表的設計
一.支付流水表 作用 主要用於記錄每一次的支付動作，主要用於，記錄使用者是否有重複支付，重複支付或者過期支付，可以用於檢查，然後退款。二訂單表 1.說訂單表，一般都是主表和子表兩個結構。1.1主表記錄買家買了什麼？付款是多少錢？總的優惠是多少？還有要發往 的位址？1.2子表主要記錄賣家的資訊，賣的是...