关于电商（虚拟商品）活动门票的表结构和业务设计

Question

方案一
目前设计的包含表结构
● 活动表（events）
● 活动门票表(events_ticket)（活动ID，票名称、图片、价格、库存、销售开始时间、销售结束时间等）
● 活动报名信息表(events_user)（姓名、公司、职位、邮箱、手机等，预留券码字段，此时为空，需要付款完生成券码）
● 订单表(order)
● 订单商品快照表(order_item)（用来保存下单时商品的快照信息，如商品图片、当时价格、数量、总额、商品标题、规格）

业务逻辑：
后台操作：创建活动-》创建门票-》发布
前台操作：访问活动-》查看活动门票-》点击购买-》填写报名信息-》点击支付-》生成报名信息记录、订单记录、订单商品记录-》支付成功-》更新订单为已完成-》报名信息里生成券码-》等待券码核销

总感觉扩展性和通用性不是很强，所以思考了另外一个方案
方案二
想把活动门票做成虚拟商品放到商品表里
● 活动表（events）
● 活动商品关联表（events_product）
● 商品表(product)（商品主题存放这里，比如某某届活动门票）
● 商品SKU表（product_sku）用于放不同的门票类型（商品ID、票名称、票图片、价格、库存、销售时间、销售结束时间）
● 订单表(order)
● 订单商品快照表(order_item)
● 订单券码表(order_voucher)

业务逻辑：
后台操作：创建活动-》创建虚拟商品（门票）-》活动里选择绑定商品？
前台操作：访问活动-》查看活动门票-》点击购买-》填写报名信息（收货人信息？）-》点击支付-》生成报名信息记录、订单记录、订单商品记录-》支付成功-》更新订单为已完成-》订单券码表生成券码-》等待券码核销

后续业务会有实物商品购买、服务购买

---

现在问题：
1、方案1这种设计有什么问题？方案2的设计是否更好？
2、方案2的报名信息再单独建张表？还是放到订单表里？券码表是不是也可以放到订单表里？
3、另外会设计购买票后，设计开发票，开票信息放订单表里，还是单独存一张表

Answer 1

我不太确定你具体业务是是哪些,那就简单说说

• 方案1这种设计有什么问题？方案2的设计是否更好

方案一我个人感觉已经很符合你的业务,设计也比较独立,不需要对现有的系统进行过多的改造,这些能保证现有系统的稳定性.

• 方案2的报名信息再单独建张表？还是放到订单表里？券码表是不是也可以放到订单表里？

如果采用方案二的话,报名信息表和劵码表可以把他单独建立起来,因为如果你什么都冗余到订单表的话,后续随着业务改变或者发展,比如说券码有过期时间,你就又要在订单表加几个字段,这样造成的结果就是表字段越来越多,越来越难以维护.而且如果你把活动门票定义为商品的话,那商品表肯定需要有一个类型来进行标记到底是门票/实物/其他类型,不然进行数据分析的时候,运营需要知道总共有多少实物商品,有多少门票.你这怎么弄.表的职责就不单一.

• 3、另外会设计购买票后，设计开发票，开票信息放订单表里，还是单独存一张表

开票信息也一样,你就觉得能省一个关联表就冗余一下数据,如果按照你的思维,这样的话这张订单表的字段就会越来越多,导致难以维护.如果想要这样可以使用mongodb来进行订单的存储或者聚合,mongodb就很适合干这种事

Answer 2

这两个设计没什么区别，局限性很大，这是因为你的业务逻辑决定的。
作为需求方进行需求描述时往往是单一的，比如你的例子就是“管理活动门票销售”，但是作为开发者需要对此分析，然后发现其实是一个复合行为，至少包括了：

1. 管理活动：让人知道有什么活动
2. 管理活动门票：参与需要购票，凭票入场，而且可能牵扯到位置问题
3. 管理销售：门票销售情况如何
4. 销售：就是支付、退款等

然后为此进行关联形成业务：用户浏览活动信息后进入门票销售页面查询价格和余票信息然后进行购买。
门票管理有两种：一种是全量预生成，就是每张票一个记录，另一种是普通的商品管理，位置属性为前排20张，位置属性为中间50张...，然后附加选座功能在销售后为每张票形成记录。

抛砖引玉，希望对你有用。毕竟别人无法从一个简单的问题中完全了解你的需求。