設計數據庫表有套路

背景

不少開發者CURD了兩三年，對數據庫表的設計仍是硬着頭皮上，一旦換了一個新的業務又不知所措，又要問一下偉大的度娘和谷哥。下面我來分享一個電商預售活動的數據庫表的設計。但願你們能夠從中收穫一些套路和方法。

預售，是商家爲了刺激消費，提早發佈商品信息，並利用優惠的提早購買政策吸引顧客預付定金購買。預售模式能快速收集消費者的訂單需求，是電商平臺最經常使用、也是最火爆的一種銷售模式

意義

• 營銷層面來講，預售能夠提早預熱活動，拉長活動週期，同時打出限時限量的噱頭，將商品打形成爆款吸引流量，產生飢餓營銷效應。
• 從技術層面來說，像雙11、618這樣的電商狂歡節開場先後的一小時中，會有大量併發交易，預售能夠有效分散下單時間，從而下降系統的峯值壓力

設計

• 預售是一個特殊類型的活動，因此必不可少有一個預售活動表

presale表（預售活動表）

pre_id 主鍵id 
pre_goods_commonid 商品SPU id，針對多SKU，這裏存的最好是common id
vid 店鋪id，針對多店鋪
pre_category 預售分類，
pre_pic 預售圖片，提升活動熱度
pre_start_time 預售開始時間
pre_end_time 預售結束時間
pre_max_buy 每人限購數量
pre_limit_time 付尾款的時間
pre_status 活動狀態，0不正常 1正常
is_rollback 庫存是否回滾

• 有活動就確定有活動商品表

pre_goods表（預售商品表）

id 主鍵
pre_id  關聯活動id
gid 商品id 最終的商品id
goods_price 商品原價
goods_name 商品名稱快照
goods_image 商品圖片快照
pre_deposit_price 商品預售定金
pre_sale_price 商品預售價
goods_stock 預售庫存

• 預售確定就要先給定金，因此下單的時候就要專門抽離出一張表，預售定金訂單表，和商城訂單表區分開，後續預售訂單付尾款的時候再轉移商城訂單表

pre_order表(預售訂單表)

order_id 主鍵,
  order_sn 訂單號,
  add_time 訂單添加時間,
  buyer_id 會員id,
  buyer_name 會員名,
  vid 店鋪id,
  store_name 店鋪名,
  pre_id 預售活動id,
  gid 商品id,
  goods_name 商品名稱,
  goods_image 商品圖片,
  goods_num 商品數量,
  goods_price 定金,
  goods_price_finish 尾款,
  order_amount 總金額,
  order_state 訂單狀態:0(取消)10(默認):未付款;20:付定金;30付尾款,
  first_time 訂單第一次支付時間(付定金),
  finished_time 訂單完成時間,
  member_message 用戶留言,
  address_id 用戶地址編號,
  true_name 用戶姓名,
  address_info 用戶地址詳細信息,
  payment_code 支付代碼,
  shipping_fee 運費

大體上就三個表就足夠，你們看完是否以爲好像也沒有套路。其實也是有的，你們沒發現我對業務的一個熟悉程度嘛，正所謂「業務驅動開發」，當你對一個業務瞭如指掌，以及瞭解整個業務鏈路的上下級關係，只要不違反基本的MYSQL規範，進行數據庫表的設計仍是遊刃有餘的。