13
回答
糟糕的设计--mysql表
1,统计表的设计。
正常的,统计表的设计是这样的。(我们这里时间以天为单位)
id - 资源id - 下载统计数 - 观看统计数 - 收藏统计数 - 时间戳
每次更新数据的时候,
update table (字段) value (数量)where id='---';(插入语句类似)
获取的时候 select (字段) from table where id=资源id。
都是这么搞的,简单的-正常的流程。

2,
而公司的表是这样设计的,奇葩设计。
资源id--下载总量
资源id--下载总量-时间戳。

资源id-观看总量。
资源id-观看总量-时戳。

资源id-收藏总量
资源id-收藏总量-时间戳。

硬生生建立了六个表。
然后,每观看一个视频,更新两次表,总量表和带时间戳的表,总量表用于统计资源被查看总量,带时间的用于时间排行榜。

我觉得这样的设计很愚蠢,设计只给的我一条理由,select 字段,要快于 select count()........
吐槽中,大家评评理。
PHP
举报
1145828184
发帖于5年前 13回/976阅
共有13个答案 最后回答: 5年前

这个设计对个屁。简直是一跎屎。互联网应用,如果完全按范式化设计,就是在找死。

一定要适当反范式化设计,才能方便使用。

其实,只需要一张表就可以了,就像楼主的那样,不需要6张表。

6张也是有6张表的好处的, 比如说你不小心看一个片片,感觉不错收藏了, 再看了意犹未尽就下载到硬盘以备不时之需.

这个过程会产生6个update操作3个事务,如果是一张表,如果每天有100w个用户类似的操作的话,你可以算算该表繁忙的程度, 可能产生的后果就是热快多,高水位线,更多的表分析和sql硬解析,体现为锁表和读写能力下降,进而影响业务开展.

表设计的范式那只是参考值,实际还是要结合自己的资源来看的,一般都是提倡用空间换时间,可以参考cpu和硬盘的价格.


设计好不好也要看具体业务和资源呢, 满足目前需要就是最好的.

--- 共有 2 条评论 ---
酷酷的就回复 @1145828184 : 先原子封装一次,在结合业务封一次,一般就没这么多了,而且也好理解了 5年前 回复
1145828184是6个update3个事务,但按我说的做就会三个update。 这三个update写数据层,不用我操心我也忍了,他生让我调用6次接口,这是我不能忍受的。 5年前 回复
顶部