现在涉及到构建后台数据库表，问题是这样的，有上千个词条，每个词条有上百个历史版本，而且可能涉及到不定期的增加历史版本的问题。怎么构建可以灵活支持以后插入新的数据就成为了一个问题。
1、最简单的想法就是把数据写在一个表中：
列：page_id(词条的id)、revision_id(词条版本的id)、text(词条的内容)
但是这样的话，表太大，现在我抓取了截止到2011年4月19号的所有英文高质量词条，共3251个。每个词条有500个历史记录（我现在想的是，500个记录会不会太多，主要是我后面分析数据的时候难度可能会增加，所以我准备减少到200个记录，最后看实验结果了。。。唉。）
2、分表，每500个词条在一个表中。
列：page_id(词条的id)、revision_id(词条版本的id)、text(词条的内容)
与第一个没什么区别，就是把大表搞小了而已
3、今天看了看wiki本身的数据库表的设计。。它的数据比我做实验的要大多了，数据库表中的关系也要复杂多了。不过也挺有收获的，最后决定我的数据库表的采用和它一致的方法。只是我的简单多了。。只涉及三个表。
(1)表page
列：page_id(词条的id)、page_name(词条的名称)
(2)表revision
列:revision_page(词条的id)、rev_text_id(词条历史版本的id)、rev_user(词条历史版本的作者)
(3)表text
列：text_id(词条历史版本的id)、text(历史记录)
----------------------------------------------------------------------------------
当然这只是表设计的一部分。表中的列没有写全。主要是记录设计的思想。
相关资源：mySql数据库在线管理系统
