如果你玩游戏的话，暴雪战网的积分就是这么设计的，现金消费可以获得积分，每次消耗积分可以换一些小礼品道具卡。
这个模式会有多重情况，比如最早的一条记录是100积分，剩余80积分，我现在要消耗50积分，直接消耗这一条就行了，另外一种情况是最早的积分记录100，剩余80，我现在要消费500积分，这一条就不够用了，所以要一次性处理多条积分记录。

假设有积分表score_records，每行含有int类型字段balance(记录该积分记录还没消费完的积分)

1、一次性查询出的数据 balance 之和刚好大于当前要消费的积分金额 total_score (SQL可以自行询问AI)

2、如果查询出的结果 balance 之和刚好是你要消费的金额，修改这些记录，表示已经消费完即可，如果 balance 之和大于你的消费金额，那么最新一条特殊处理，只消费部分，前面的前部改为消费完即可。

记得加锁，防止重复消费一条记录，由于积分只能获得，已经获得的记录不会出现修改，每个用户加一把积分消费锁就可以了

引入课次概念 然后排课

在用户对象（表）上新增两个属性（字段），表示用户的购买课时和赠送课时时长。消耗时先消耗购买课长，直接扣减即可 ，不够扣了扣赠送，赠送也不够扣报异常。 做个明细记录，买了就新增一条加的，新增一条赠送的。消耗了就增加一条减的。

应该是用户表,订单表,订单商品(课时)表,课时日志表

一个订单里有正价课时,赠送课时,每种课时是一件商品,算一条记录,每条记录有总课时,已用课时,剩余课时,可以加个优先级和分类字段

约课的时候只查剩余课时大于0的,再按照优先级,分类消耗,记录到日志表,关联课时表

用数据库的窗口函数查询就行了，每次查询的记录是可用课时刚好等于扣减的数量或者多一条记录，然后按需要的顺序依次扣减每个记录的可用课时

咋感觉这个架构不太合理呢，买的是课时，消耗的也是课时，为啥消耗课时的时候需要操作原始的购买订单呢，这俩应该解耦才对

你不妨说说你现在的设计的怎么样的，然后觉得这样的设计有哪些不能克服的缺点

Laravel 课时消耗系统设计

针对学生课时消耗的需求，我建议采用以下设计方案：

核心设计思路

1. 订单与课时消耗解耦：通过中间表记录课时消耗情况
2. 消耗顺序：先消耗购买课时，再消耗赠送课时
3. 撤销功能：记录每次消耗的日志，便于撤销
4. 多订单处理：按订单创建时间顺序处理

pastebin.com/e297v8EX

加一个user_packages记录所有充值的套餐，内部可以加金额用量，实际付款金额等字段