这是一个创建于 1173 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前在开发一个优惠券的功能，卖家可以创建优惠券，买家可以领取卖家创建的优惠券。
api 初步的设想是：
卖家：
创建 POST /coupons
修改 PATCH /coupons/{id}
获取 GET /coupons
现在纠结的是买家的设计，原先的想法是:
领取 POST /buyer/coupons/{id} or {code}
获取 GET /buyer/coupons
如果是这样的设计的话，担心的一个点是，coupons 的概念会不会卖家与买家的混淆了，与之而来的买家优惠券 id 是该取名为 buyerCouponId 这样么，毕竟要与卖家的优惠券 id 给区分开来。
或者买家的 api 是不是可以设计成:
领取 POST /buyerCoupons/{id} or {code}
获取 GET /buyerCoupons
底层表命名的话，应该就是 coupon 表与 buyer_coupon 表这样。
还请各位大佬指点一下。
谢谢。
 |
1
cpstar 2021-09-07 16:41:06 +08:00
/merchant/coupon
/consumer/coupon |
 |
2
shanghai1943 OP @cpstar #1 感谢回复。按您的意思，买家的优惠券 id 的命名就是 consumerCouponId，卖家的就是 merchantCouponId 了吧？
|
|
3
cpstar 2021-09-07 16:55:11 +08:00
还得考虑这两个 coupon 之间的关联关系
这就是数据库或者系统设计里的『分析实体』，你先弄清楚，这两个 coupon 是不是一个 coupon，是两个独立的实体，还是一个实体派生出的两个实体。 |
|
4
shanghai1943 OP @cpstar #3 从功能上看，买家的优惠券是从卖家那里领取过来的，设计表结构的时候就是优惠券实体表 coupon，以及买家领取后的关联表 buyer_coupon，里面包含有买家账号 id 和 coupon 表的 id，比如 coupon_id，并且 buyer_coupon 里会记录是否使用过该优惠券之类的信息。
目前纠结的点，买家的优惠券是否可用 buyer_coupon 来表达，卖家创建的优惠券就默认用 coupon 来表达，不知这种方式是否可行。 |
|
5
cpstar 2021-09-07 17:09:50 +08:00
所以就一个实体呗，coupon，卖家生成，买家领取
那接口岂不就是 生成 COUPON POST /coupon 领取 COUPON PATCH /coupon/{id} 第二个岂不是跟卖家修改一致了？那是一致啊，因为买家的领取，某种意义上是修改了 coupon 的关联关系，与（卖家）修改 coupon 是一种行为。 当然这是建议，如果嫌一个接口，还要区分到底是修改还是领取，很麻烦，那就分开，就是你问题中的思路了。 |
|
6
cpstar 2021-09-07 17:11:48 +08:00
关于 coupon 的表结构设计，理论上应该三个实体表，COUPON, MERCHANT, CONSUMER，以及两个关联表，COUPON_MERCHANT, COUPON_CONSUMER，但是后两者如果都是 1:1 的关系，可以合并进 COUPON，两个“外键”关联到 MERCHANT 和 CONSUMER
|
 |
7
qfdk 2021-09-07 18:20:36 +08:00 via iPhone
记得 加上 if qfdk isFree
|
 |
9
ieiayaobb 2021-09-07 19:39:32 +08:00
买家，卖家的 id 要区分开来的意图是啥？
|
|
11
shanghai1943 OP @ieiayaobb #9 主要是为了避免沟通上的歧义。因为买家领了优惠券之后，相当于也有自己的优惠了，那相应的会存在一个优惠券 id 的说法，用于下单的时候指明是消费哪张优惠券。卖家那边创建了优惠券，所以也会有优惠券的 id 这种说法。需要从设计层面去解决这个沟通歧义的问题。
|
|
12
shanghai1943 OP @cpstar #10 额。这是 v 站的什么隐藏彩蛋吗
|
Select Language