表结构设计案例：每天签到赠送 30 天 1G 的云空间，怎么设计更合理

你这每次都固定容量没必要记录明细了吧

@bk201 不然怎么计算目前用户还有多少有效期内的空间

目前表结构图：

不是很熟悉这块
总空间大小可以后台在取的时候计算？

你只要记录签到时间，然后统计下有效签到次数就行了吧

1 、每个用户的每次签到完全不需要做成一条记录，存一个 uint32，每次读出来然后设一下当天签到与否为 1 不就行了？这样一年也就 12 条记录。
2 、超过两个月以上的记录完全可以删除。每个月可以倒腾一次表，比如拷贝成一个新的表然后把原来的表删掉之类的。

应该还要记录赠送时间，
比如业务变化，赠送 90 天 100GB 呢？
每一条记录都可能赠送不一样的内容

每次都要计算效率太低了，不如签到时直接加上 1G 空间，同时添加一个 30 天后减掉 1G 空间的任务。

减空间的任务可以记录在一张表里，只需日期和用户 ID 两列。定时任务每天跑一遍，读取今天需要减的用户 ID，然后减

3. 对于空间那就好办了。容量可以分为几种来源：基础的、收费的、签到赠送的。然后在签到赠送上面每天刷新一下容量就行了。

@ipwx
用 uint32 存的话，前提是每天签到的容量是固定的，这样处理确实数据量会小很多。

确实存在收费购买的空间，按照这个流程的话只能是每天跑下定时任务计算下总空间大小。

@qsnow6 其实不一样也没啥，每个用户一行远比每个用户 365 行要快得多，哪怕你把所有每个用户有关的东西都丢进一个 column 里面了。postgresql 的 json 字段不就干这件事么。。。

而且哪怕没有定时任务，你每个用户登录的时候顺带刷新一下这个字段和总空间容量都来得及。

你目前设计的这种明细表是正确合理的，也便于之后客服扯皮，尤其是你们还有销售业务。
而每次都要统计总容量应该也是一个正确的操作吧？为啥你会认为不合理呢。
当然，前提是如何触发“每次”，我认为这里主要指的是每次明细表里面有更改，譬如每次签到或者每次购买后应该立刻统计刷新。
清理过期容量可以做成定时任务，但清理之后不需要立刻重新统计每个用户的容量
可以在每次用户登录或者上传时做一个判断，例如判断用户上次刷新时间和系统定时清理两个时间点，如果早于清理时间，那么需要重新统计，否则略过

类似于#8 楼的方案就可以，每次签到发一个消息，通过消息创建一个定时任务，到期减掉就可以，容量这些也可以是其他数值。

@Rocketer @DeutschXP @liuguangcuican42 8 楼这个方案开销确实更小，而且少了汇总计算的过程，只要确实定时任务能正确执行不出差错就行。

@qsnow6 这主要取决于这个功能的要求是什么级别了，以及用户规模。
看你的意思倾向于 8 楼的方案，那么说明这应该就是一个游戏积分系统，那就不是重要级别，即使出错也正常。譬如 V2EX 的铜币积分，应该也没人会真正在乎到底有没有签到成功，发帖子会不会多扣分了。
主要你说你们也有销售业务，所以会认为每一笔交易（包括免费赠送）都要有明细，你看移动联通送话费送流量也不会说简单的加一下减一下，你查账单必然能看到每一笔操作。
但联通每天打卡送金币就不会那么严谨了，反正送的又不是钱。

@qsnow6 补充一下，不知道你们目前整体的结构，就提出一个场景：你们明天推出购买 100G 送 20G 的活动，然后一个人找你们客服，说送的 20G 没有到账，那么你就需要区分，签到的免费空间和这个活动送的空间。
或者你们新年搞个转盘抽奖，有个人说我抽了 1G，但是没有到账，你一查定时记录，30 天后确实有一个删定时删除任务，但你其实也无法确定，这个任务是签到创建的还是抽奖创建的，那你就需要额外的字段或者表格来区分。

@DeutschXP 感谢解答，确实经常会收到客服那边的反馈其它业务模块经常有扯皮的，所以明细还是要记录详细的日志，方便客服来回溯。