老大：帮忙设计一下数据库,该如何处理

老大：帮忙设计一下数据库
我想做一个RSS资讯聚合网站，把所有的RSS订阅信息缓存进数据库，再被页面调用。
数据表大致需要以下字段：

id（自动增加）,title（资讯标题）,content（资讯内容）,image（图片）date（资讯时间）,source（资讯源网站名）,url（资讯文章的超链），category（类别），province（省），city（城市）。

每天数据更新量大约有三万条，所有的信息缓存一年（一年后大致会有30多万条数据量）。类别分了52个。城市有73个。

我这样的情况，如何设计数据库？

如果所有的都设计进一个表，站内搜索容易设计，但30多万条数据加那么多字段名，页面调用数据会不会很慢？
如果分表的话，怎样分最合理？还需要考虑写站内搜索的代码。谢谢。

------解决方案--------------------
像这种schema简单的用不着关系数据库
注意俩问题就行
1.性能 2.扩展性

要是考虑功能的扩充，像全文检索之类的，关系数据库更不适合

你用MongoDB吧，做这个正合适

结构就按你想的就成