先上表结构图, 我这里用的MySQL数据库, 表结构如下
对应建表SQL:
create table cdk(
id int(11) unsigned not null primary key auto_increment,
cdk varchar(16) not null comment '兑换码',
cdk_kind tinyint not null comment '兑换类型 1-会员卡, 2-优惠券, 3-优惠券包',
cdk_kind_no varchar(32) not null comment '兑换类型编号',
cdk_status tinyint not null default 1 comment '兑换码使用状态 1-未使用, 2-已使用',
cdk_export_status tinyint not null default 1 comment '兑换码导出状态 1-未导出, 2-已导出',
act_account_id int(11) comment '使用人',
act_time datetime comment '使用时间',
gen_account_id int(11) comment '生成人',
gen_time datetime comment '生成时间',
export_account_id int(11) comment '导出人',
export_time datetime comment '导出时间',
valid_time datetime comment '有效期开始时间',
expire_time datetime comment '有效期失效时间',
remark text comment '备注',
create_time datetime not null default current_timestamp comment '创建时间',
update_time datetime not null default current_timestamp on update CURRENT_TIMESTAMP comment '更新时间',
unique key(cdk)
)engine=innodb comment '兑换码';
设计说明
1.兑换码与兑换商品类型:
一个表中可以维护所有可以通过兑换码兑换的商品的兑换码, 使用cdk_kind区分不同的商品类型, 使用cdk_kind_no区分某个商品下更具体的商品. 比如你平台共有两种会员卡, 编号分别为"VIP"和"SVIP", 则cdk_kind=1, cdk_kind_no分别为"VIP"和"SVIP".
cdk字段为兑换码, 这里是此字段单独作为唯一索引. 另有方案可以用cdk字段与cdk_kind一起做联合唯一索引.
cdk字段单独做唯一索引, 则只需要设计一个兑换页面, 换到什么就是什么, 当然也可以多个兑换入口页面, 调同一个接口就行;
cdk字段与cdk_kind做联合唯一索引时, 意味着同一个兑换码在不同的地方可以兑换不同的商品, 需要多个入口或者一个入口时需要选择兑换的商品类型.
如果有新的商品需要参与使用兑换码兑换, 只需要新增cdk_kind字段的枚举.
兑换码服务与被兑换商品的服务之间, 可以兑换码服务直接调用被兑换商品的服务, 也可以兑换码服务将兑换信息放入消息队列, 被兑换商品的服务消费消息处理兑换入账.
2.兑换码兑换之后, 对应记录由1-未使用状态变为2-已使用状态.
3.导出状态, 即为兑换码是否出库的状态. 刚生成出来时为1-未导出状态, 可以通过从管理后台下载到excel等方式出库, 出库后及改为2-已导出状态, 标识这个兑换码已经有人预定了, 不能重复给另一个人.
同时, 管理后台最好设计兑换码不可见, 即不在页面展示兑换码的号码, 避免能见到的人把未导出状态的码直接给出去使用, 也可以避免有人将别人已导出但未使用的码提前使用.
4.兑换码可以设计有效期开始和结束时间, 时间范围内才可以兑换. 可以用在某些特定的场景下. 比如某个会员卡需要一周之后才上线, 但可以提前将其兑换码上线. 指定一周之后才生效.
5.为避免多个人同时导出兑换码的冲突, 建议遵循谁生成谁导出的原则, 即设计中的gen_account_id-生成人字段与export_account_id-导出人字段, 与当前登录的的账号id一致.
假如有用户a和用户b两个人在几乎同时操作导出, 用户a需要100个, 用户b需要10个, 在用户a生成了100个的时候, 用户b发现库中有足够的未导出状态的码, 则可能自己不会生成, 而是把用户a生成的100个中的10个抢先导出了. 而如果遵循"谁生成谁导出"则可以避免此类问题.