我之前曾参与维护过一个舆情监控系统，该系统每天源源不断地监控着互联网上的新闻，不断从网上下载新闻保存进入数据库。

提出问题

　　为了表述简单，我特意模拟了一张类似的表：

　　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