1.库中的积分记录应该都有时间戳,如果没有我也不知道如何回答2.sql查询时通过查询函数指定date起止区间,例如date位于[注册时间-2017/10/25]区间内的所有积分数据对积分字段,例如score字段求sum例如 select sum(us.score) as score_at_day from user_score as us join user as u where us.timestamp > u.register_time and us.timestamp < $1(查询的日期date值) 我以前做类似功能大致是如此写的,这条sql我没有去测 随意写的大概是这个意思吧3.HQL封装或写成存储过程 4.根据题主要求希望使用定时器记录每天的积分值优点:后续查询效率比这种查询快速一点缺点:需要扩展表关系,用户与每日的历史积分也是一个1-N关系,本身用户与单次积分累计已经是一个1-N关系了,逻辑上会增加你维护的难度,以及增加空间的开销 5.我说的这种方式不需要维护额外的表,每个用户具体日期的历史积分在具体查询时才会去计算,逻辑在sql层,能稍微增加一些资源利用率:比如当很多用户不喜欢查询自己的历史积分时,不会做任何的事情 补充下,上面那种sql中的 us.timestamp < $1(查询的日期date值) 对你的问题好像没啥关系,我以前这么写是因为业务逻辑既需要统计历史总积分,也要分别计算各月、各年、各日的积分,才这样弄得。具体你可以看看这个网站的右下角有个本周/本月积分排行榜,我相信他们应该也有一个时间区间的概念,而不是每天单独存表
1.库中的积分记录应该都有时间戳,如果没有我也不知道如何回答
2.sql查询时通过查询函数指定date起止区间,例如date位于[注册时间-2017/10/25]区间内的所有积分数据对积分字段,例如score字段求sum
例如
我以前做类似功能大致是如此写的,这条sql我没有去测 随意写的大概是这个意思吧
3.HQL封装或写成存储过程
4.根据题主要求希望使用定时器记录每天的积分值
优点:后续查询效率比这种查询快速一点
缺点:需要扩展表关系,用户与每日的历史积分也是一个1-N关系,本身用户与单次积分累计已经是一个1-N关系了,逻辑上会增加你维护的难度,以及增加空间的开销
5.我说的这种方式不需要维护额外的表,每个用户具体日期的历史积分在具体查询时才会去计算,逻辑在sql层,能稍微增加一些资源利用率:比如当很多用户不喜欢查询自己的历史积分时,不会做任何的事情
补充下,上面那种sql中的 us.timestamp < $1(查询的日期date值) 对你的问题好像没啥关系,我以前这么写是因为业务逻辑既需要统计历史总积分,也要分别计算各月、各年、各日的积分,才这样弄得。
具体你可以看看这个网站的右下角有个本周/本月积分排行榜,我相信他们应该也有一个时间区间的概念,而不是每天单独存表