学生A有多个记录数据，每个记录数据还有赠送课时，每次上完课先把购买的消耗完，然后再消耗赠送的，如果这个订单消耗完毕，去下一个订单数据里面查询，直至可以扣除完毕，程序怎么设计会比较好点呢？
如果你玩游戏的话，暴雪战网的积分就是这么设计的，现金消费可以获得积分，每次消耗积分可以换一些小礼品道具卡。
这个模式会有多重情况，比如最早的一条记录是100积分，剩余80积分，我现在要消耗50积分，直接消耗这一条就行了，另外一种情况是最早的积分记录100，剩余80，我现在要消费500积分，这一条就不够用了，所以要一次性处理多条积分记录。
假设有积分表score_records，每行含有int类型字段balance(记录该积分记录还没消费完的积分)
1、一次性查询出的数据 balance 之和刚好大于当前要消费的积分金额 total_score (SQL可以自行询问AI)
2、如果查询出的结果 balance 之和刚好是你要消费的金额，修改这些记录，表示已经消费完即可，如果 balance 之和大于你的消费金额，那么最新一条特殊处理，只消费部分，前面的前部改为消费完即可。
记得加锁，防止重复消费一条记录，由于积分只能获得，已经获得的记录不会出现修改，每个用户加一把积分消费锁就可以了
在用户对象（表）上新增两个属性（字段），表示用户的购买课时和赠送课时时长。消耗时先消耗购买课长，直接扣减即可 ，不够扣了扣赠送，赠送也不够扣报异常。 做个明细记录，买了就新增一条加的，新增一条赠送的。消耗了就增加一条减的。
应该是用户表,订单表,订单商品(课时)表,课时日志表
一个订单里有正价课时,赠送课时,每种课时是一件商品,算一条记录,每条记录有总课时,已用课时,剩余课时,可以加个优先级和分类字段
约课的时候只查剩余课时大于0的,再按照优先级,分类消耗,记录到日志表,关联课时表
咋感觉这个架构不太合理呢，买的是课时，消耗的也是课时，为啥消耗课时的时候需要操作原始的购买订单呢，这俩应该解耦才对
你不妨说说你现在的设计的怎么样的，然后觉得这样的设计有哪些不能克服的缺点
针对学生课时消耗的需求，我建议采用以下设计方案：
加一个user_packages记录所有充值的套餐，内部可以加金额用量，实际付款金额等字段
你的要求是必须先消费之前的订单，那么可以打开一个思路，先把所有记录包括赠送的时长冗余到一个字段balance, 然后每次消费先判断当前消费时长是否小于balance，如果满足条件则扣减balance，然后升序查询之前的订单明细表出来后扣减。这样你需要保证冗余出来的balance和订单明细表时长的一致性
用户表user，再加一个user_balance 用户账户表，还有一个user_balance_change_log表，解决不了吗。你这个问题应该就是同一个账户（课时）多个余额记录问题
我们是做了一个课次服务，不同的课是不同的账号，然后规划入班会冻结，上课完成再扣减，退班会退回
请登录
关于 LearnKu
粤公网安备 44030502004330号
在用户对象（表）上新增两个属性（字段），表示用户的购买课时和赠送课时时长。消耗时先消耗购买课长，直接扣减即可 ，不够扣了扣赠送，赠送也不够扣报异常。 做个明细记录，买了就新增一条加的，新增一条赠送的。消耗了就增加一条减的。