设计数据库表有套路

背景

不少开发者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规范，进行数据库表的设计仍是游刃有余的。