卖家可以设置一类商品在价格高于 x 元时每分钟自动降价 y 元，请问如何设计数据库效率最高？
rv54ntjwfm3ug8 · 2021-04-10 12:02:20 +08:00 via iPhone · 2069 次点击这是一个创建于 1308 天前的主题，其中的信息可能已经有所发展或是发生改变。
需要如何分表和设置索引呢？将对整个分类的设置复制到每个商品能够提高效率吗？
 |
1
MeteorCat 2021-04-10 12:10:53 +08:00 via Android
商铺价格自动降价字段或者降价规则，用户访问的时候判断当前价格高于 X 元，高于 X 元跑降价字段或者降价规则
|
 |
2
learningman 2021-04-10 12:11:32 +08:00
保存开始降价的 timestamp，当前价格计算得出行不？
|
 |
3
rv54ntjwfm3ug8 OP  1
|
 |
4
xuegy 2021-04-10 12:21:54 +08:00 via iPhone
后台跑一个进程一直不停的排序吧。应该没什么特别好的算法，因为降价的开始 /结束时间都不一致。
|
 |
5
markgor 2021-04-10 12:25:36 +08:00
目标：商品类别。
逻辑：高于 X 元每分钟自动减少 Y 元。 不确定因素： 商品价格扣减 Y 元后是否允许高于 X 元？ 每分钟自动降价是否有个价格 /时间阈值？ 多一个条件和少一个条件做法都不一样，建议先确定好需求，再想方法。 |
 |
6
pimin 2021-04-10 12:29:26 +08:00
显示价格是计算价格，数据库效率最高
至于排序，如果商品数量不是超级多，比如只有几百条几千条，维持一个实时价格榜单，在需要排序的时候调用就行。 |
|
7
rv54ntjwfm3ug8 OP 1
|
 |
8
pkupyx 2021-04-10 13:52:02 +08:00
具体电商业务理论上每次编辑商品信息都得创建新的商品快照，编辑价格也一样。所以创建假超管账户，然后走人工编辑创建快照的逻辑吧。
|
 |
9
no1xsyzy 2021-04-10 18:41:27 +08:00 1
显然应该用 redis 作排序啊（笑
@markgor “每分钟”显然蕴含了你可以指望大部分情况下扣减 Y 元后是高于 X 元的。 也一定程度上暗示了终止条件是价格不高于 X 元为止。 但不确定因素还有： 如果输入错误，Y>X 是否会导致价格为负？（因为可能越过“用户输入校验”） 是否可能导致长时间大量行更新？表的大小是多少？数据库撑得住吗？ 除此以外，这种逻辑简直是跟商业技巧反着来的：每等分钟你都能获得更优惠的价格，那么几乎所有人都会等价格降低，而一旦等待，就会造成强制冷静反思自己是不是需要这个商品。为了抵抗强制冷静，必须设置商品数量有限，实质是带一口价的拍卖，请直接换成拍卖。 |
 |
10
MintZX 2021-04-11 06:51:12 +08:00
什么数据库？ postgres 写个 procedure 用 pg_cron 后台 run 就行了
ms sql server 也有同样的功能 |
 |
12
DoctorCat 2021-04-11 17:49:09 +08:00 1
lz 这明显是动态字段嘛，保留原价格字段，然后额外增加一个状态字段最好。
这似乎跟分表没啥必然联系啊。如果是为了提升效率那就增加一个动态计价的服务通过商品表中的状态字段关联，把价格计算与最终成交订单数据分离，服务挂了可以降级为：价格不变原价交易。 |
 |
13
hui314 2021-04-12 11:06:20 +08:00
redis 有序集合， 商品 id 为 key， 价格为 score.
|
Select Language