【开源中国 APP 全新上线】“动弹” 回归、集成大模型对话、畅读技术报告”
1,统计表的设计。
正常的,统计表的设计是这样的。(我们这里时间以天为单位)
id - 资源id - 下载统计数 - 观看统计数 - 收藏统计数 - 时间戳
每次更新数据的时候,
update table (字段) value (数量)where id='---';(插入语句类似)
获取的时候 select (字段) from table where id=资源id。
都是这么搞的,简单的-正常的流程。
2,
而公司的表是这样设计的,奇葩设计。
资源id--下载总量
资源id--下载总量-时间戳。
资源id-观看总量。
资源id-观看总量-时戳。
资源id-收藏总量
资源id-收藏总量-时间戳。
。
硬生生建立了六个表。
然后,每观看一个视频,更新两次表,总量表和带时间戳的表,总量表用于统计资源被查看总量,带时间的用于时间排行榜。
我觉得这样的设计很愚蠢,设计只给的我一条理由,select 字段,要快于 select count()........
吐槽中,大家评评理。
目测设计是想统计小时, 天, 月的次数。
1张表足够了, 前面用缓存先挡着, 晚上用脚本跑进库里。