这是一个创建于 1159 天前的主题，其中的信息可能已经有所发展或是发生改变。
有个产品的需求是这样的，用户每天来签到，每次签到赠送 30 天 1G 的云空间，并且可以进行累加，到期后空间收回。
基于这样的需求，我的设计是增加一个表，记录不同来源的会员开通时间，表结构是：开始时间、结束时间、容量。
这个表结构的问题是每次都要进行汇总计算用户的总空间大小，有没有更合理的结构或者流程？
 |
1
bk201 2021-09-24 13:49:26 +08:00
你这每次都固定容量没必要记录明细了吧
|
 |
3
qsnow6 OP 目前表结构图：
 |
 |
4
kiritoxf 2021-09-24 14:11:46 +08:00
不是很熟悉这块
总空间大小可以后台在取的时候计算？ |
|
5
bk201 2021-09-24 14:12:27 +08:00
你只要记录签到时间，然后统计下有效签到次数就行了吧
|
 |
6
ipwx 2021-09-24 14:17:41 +08:00
1 、每个用户的每次签到完全不需要做成一条记录，存一个 uint32，每次读出来然后设一下当天签到与否为 1 不就行了？这样一年也就 12 条记录。
2 、超过两个月以上的记录完全可以删除。每个月可以倒腾一次表，比如拷贝成一个新的表然后把原来的表删掉之类的。 |
 |
7
w292614191 2021-09-24 14:18:05 +08:00
应该还要记录赠送时间，
比如业务变化，赠送 90 天 100GB 呢？ 每一条记录都可能赠送不一样的内容 |
 |
8
Rocketer 2021-09-24 14:18:20 +08:00 via iPhone
每次都要计算效率太低了，不如签到时直接加上 1G 空间，同时添加一个 30 天后减掉 1G 空间的任务。
减空间的任务可以记录在一张表里，只需日期和用户 ID 两列。定时任务每天跑一遍，读取今天需要减的用户 ID，然后减 |
|
9
ipwx 2021-09-24 14:18:55 +08:00
3. 对于空间那就好办了。容量可以分为几种来源：基础的、收费的、签到赠送的。然后在签到赠送上面每天刷新一下容量就行了。
|
|
10
qsnow6 OP |
|
11
ipwx 2021-09-24 15:34:48 +08:00
@qsnow6 其实不一样也没啥，每个用户一行远比每个用户 365 行要快得多，哪怕你把所有每个用户有关的东西都丢进一个 column 里面了。postgresql 的 json 字段不就干这件事么。。。
而且哪怕没有定时任务，你每个用户登录的时候顺带刷新一下这个字段和总空间容量都来得及。 |
 |
12
DeutschXP 2021-09-24 16:59:23 +08:00 via iPhone
你目前设计的这种明细表是正确合理的，也便于之后客服扯皮，尤其是你们还有销售业务。
而每次都要统计总容量应该也是一个正确的操作吧？为啥你会认为不合理呢。 当然，前提是如何触发“每次”，我认为这里主要指的是每次明细表里面有更改，譬如每次签到或者每次购买后应该立刻统计刷新。 清理过期容量可以做成定时任务，但清理之后不需要立刻重新统计每个用户的容量 可以在每次用户登录或者上传时做一个判断，例如判断用户上次刷新时间和系统定时清理两个时间点，如果早于清理时间，那么需要重新统计，否则略过 |
 |
13
liuguangcuican42 2021-09-24 17:07:46 +08:00
类似于#8 楼的方案就可以，每次签到发一个消息，通过消息创建一个定时任务，到期减掉就可以，容量这些也可以是其他数值。
|
|
14
qsnow6 OP |
|
15
DeutschXP 2021-09-25 21:59:16 +08:00 via iPhone
@qsnow6 这主要取决于这个功能的要求是什么级别了，以及用户规模。
看你的意思倾向于 8 楼的方案，那么说明这应该就是一个游戏积分系统，那就不是重要级别，即使出错也正常。譬如 V2EX 的铜币积分，应该也没人会真正在乎到底有没有签到成功，发帖子会不会多扣分了。 主要你说你们也有销售业务，所以会认为每一笔交易（包括免费赠送）都要有明细，你看移动联通送话费送流量也不会说简单的加一下减一下，你查账单必然能看到每一笔操作。 但联通每天打卡送金币就不会那么严谨了，反正送的又不是钱。 |
Select Language