这是一个创建于 272 天前的主题，其中的信息可能已经有所发展或是发生改变。
典型 order -> order item 表怎么承载 “曾经购买” 这样的功能？
这个是不是应该另外冗余一张表来存储 “用户 -> 购买过的商品” 的关联关系？
14 条回复 • 2024-03-29 16:10:23 +08:00
 |
1
aino 272 天前
我来写的话，啥都不用设计了，order 表中肯定关联了商品表，关联查询就不就知道了这个商品是否曾经购买。
|
 |
2
justdoit123 OP @aino 是这样的，能关联查询出来。 问题是，这个关联查询 目前只能通过 user_id 找到购买的 order 记录，然后从 order 再关联 order_item 表，找到曾经购买过的商品。
这个查询在新的需求里，很高频。暂时是加 redis 缓存，但是这种 per user 的查询，缓存命中率不太高。 |
 |
3
felmoon 272 天前
后期还要对曾经购买做分析呢
|
|
4
aino 272 天前  1
@justdoit123 #2 为啥 缓存命中率不太高，没做缓存预热嘛，可以做一遍缓存预热嘛
|
|
5
justdoit123 OP @aino 命中不高 是跟 产品 做对比的，个人感觉而已。也行，那就对近期活跃用户做下预热。感谢~
|
|
6
justdoit123 OP @felmoon 后期分析更多的时候是离线计算，暂时不用考虑。
|
 |
7
me1onsoda 272 天前
你冗余了另一张表，其实不还是复制一张了 order 表😂
|
 |
8
javalaw2010 272 天前
那就 order_item 表冗余一个 user_id 字段，然后查 order_item 表即可。
|
 |
9
dongzhuo777 272 天前
order_item 做冗余，加一个 user_id 。。。我司之前的表就是这样处理起来顺手多了
|
|
10
justdoit123 OP @javalaw2010 那还得把 order 的状态也冗余到 order_item 里，要考虑到有些 order 是没支付就被关闭的。
|
|
11
justdoit123 OP @me1onsoda 所说的那种冗余方案，只需要冗余 user_id -> {product_id, order_id} ，不需要冗余整个 order 表。说到底，这种表更像是归档记录。
|
|
12
javalaw2010 272 天前
@justdoit123 #10 那就干脆 user_id 也别冗余了，直接两表 join 一下，单个用户的订单数不会太多，这个性能应该是可接受的。
|
|
13
justdoit123 OP @javalaw2010 嗯，是的。目前就用这个方案。
|
 |
14
wumou 272 天前
直接加张表，user_id , product_id , count
|
Select Language