标签:
我之前曾参与维护过一个舆情监控系统,该系统每天源源不断地监控着互联网上的新闻,不断从网上下载新闻保存进入数据库。
为了表述简单,我特意模拟了一张类似的表:
CREATE TABLE NEWS( Id int PK, Title nvarchar(500) --新闻标题 Content text --新闻内容
CreateTime DateTime
)
随着时间的推移,数据库里的新闻变得越来越多,系统开始跑得越来越慢。随后,技术经理考虑到,舆情监控需要的仅仅是近期的数据,过时的数据,不太重要。于是,新建了一个表,该表以时间命名,字段一样:
CREATE TABLE NEWS2009( Id int PK, Title nvarchar(500) --新闻标题 Content text --新闻内容
CreateTime DateTime
)
1、不断产生的新表
照我的估计,这个数据库之后还会有
News2010,News2011,News2012.......
添加时需要选择表:
由于数据要被拆分到不同的表中,假如系统不似我的舆情监控系统一样,不断有不同时间的数据录入,那么根据不同的数据,选择不同的数据添加就成了你的责任。
INSERT INTO NEWS2010 (2010年的数据)
特殊时间点:
如果元旦到了,你还在享受着美满的假期,突然客户打电话来,问系统为什么不监控了,shit,2013.1.1你忘了建新表。导致大量数据漏掉了,你难免比老板痛扁一顿。
2、管理数据完整性
加入某一天,你运行:
SELECT * FROM NEWS2009 WHERE CreateTime NOT BETWEEN ‘2009-01-01‘ AND ‘2009-12-31‘
结果居然有返回,那么你又有麻烦了。为了避免这种情况,你不得不对每一张新闻表添加约束,不在规定时间内的数据,不允许添加规定的表。
3、同步数据
突然,产品经理要求将几条数据的CreateTime由进库时间,改为新闻网站的发布时间。例如有一点时是2010-01-02,但实际发布时间稍早是2009-12-31。
你满怀自信兴冲冲地敲入:
UPDATE NEWS2010 SET CreateTime = ‘2009-12-31‘ WHERE Id = 12345
运行时,突然一想,这数据变成了一条无效数据,它应该存入NEWS2009这张表中。UPDATE无用了,你必须添加进NEWS2010然后再删除本条数据。
4、确保唯一性
分割出来的数据,其主键要在所有年份的表里都是唯一的,如果你要从NEWS2010表移一条数据到NEWS2009表,那么你得确保主键不会冲突。你不得不自己实现主键策略。
5、跨表查询
假如老板要每年2月14号的数据报表。你不得不拼命地
SELECT * FROM NEWS2009 UNION SELECT * FROM NEWS2010 UNION SELECT * FROM NEWS2011 . . .
6、同步元数据
假如产品经理突然要求所有新闻添加一个字段,那么你不得不ALTER多张表。
7、管理引用完整性
假如产品经理要求评论也一起抓取回来,NEWS表的NEWSID不行被Comments评论表引用,那么这个外键不得不被关键多张表。
基于以上种种分析,明显已经看出,这样的设计不是一个好的设计。
对于这种时间效应比较强,数据比较多的表,我们应该博览群魔,分区表。
关于分区表的实现,之前已经写过http://www.cnblogs.com/kissdodog/p/3156758.html
标签:
原文地址:http://www.cnblogs.com/mingxuantongxue/p/4655161.html