糟糕的设计--mysql表

1145828184 发布于 2013/12/23 12:17
阅读 978
收藏 5
PHP
1,统计表的设计。
正常的,统计表的设计是这样的。(我们这里时间以天为单位)
id - 资源id - 下载统计数 - 观看统计数 - 收藏统计数 - 时间戳
每次更新数据的时候,
update table (字段) value (数量)where id='---';(插入语句类似)
获取的时候 select (字段) from table where id=资源id。
都是这么搞的,简单的-正常的流程。

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

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

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

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

我觉得这样的设计很愚蠢,设计只给的我一条理由,select 字段,要快于 select count()........
吐槽中,大家评评理。
加载中
0
月影又无痕
月影又无痕

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

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

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

0
xuehao822
xuehao822
菜鸟同意楼上
0
冰冰鱼
冰冰鱼
蛮对的 
0
冰冰鱼
冰冰鱼
参照下范式
0
Tuesday
Tuesday

目测设计是想统计小时, 天, 月的次数。

0
酷酷的就
酷酷的就

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

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

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


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

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

1张表足够了, 前面用缓存先挡着, 晚上用脚本跑进库里。


0
羊驼君
羊驼君
肯定是当成了NOSQL的存储方式。
0
大喵哥
大喵哥
设计成这样 是不是当初有考虑到什么原因的啊? 你问问公司相关的人员
0
张文亮
张文亮
适当分表冗余有时候对特定访问有好处。
返回顶部
顶部