接客户的要求，4个ZBLOG ASP站点，合并到同一个ZBLOGPHP，要求文章URL保持不变。
大概介绍一下四个站的数据情况。
1、主站mssql，三个子站使用的是access。
2、文章大概加起来6000多
3、评论大概不到100万
4、标签大概不到一千。
5、分类总计十几个的样子。
最开始想的总是简单
接单的时候想法也是比较简单的，只是没想到数据量比较大的时候，官方提供的转换工具都沦陷了：
1、a2p Z-BlogPHP转换工具 这组插件在导出数据的时候，随机抽风，乱码。无法使用。
2、MovableType数据格式导出，基本上如果100篇导出一次是可以的。但是数据太多的时候……无法使用。
好像只有这两个插件？
提出问题
然而更困扰的是，没人操作过多个ASP转入同一个PHP站的事情，这有很多需要引入的问题。
1、文章ID重复，多个站点ID都是从1开始累加的，分类、评论、tag、用户也有这个问题。
2、简单无脑的修改文章ID，会导致评论错乱，A文章的评论可能会跑到B文章下面去，分类和Tag也有这个问题。
3、ZBLOG的文章url，在没有设置文章的别名Alias的时候，是和文章ID强关联的，如果修改了文章ID，那么Url也会跟着变化。
解决问题
鉴于以上这些问题，经过思考和验证，可以通过以下方式来进行合并解决。
1、对四个站的数据库中的文章、分类、评论、标签，主ID进行备份。因为access可能无法一次执行多条sql语句，所以只能一条一条复制过去执行...
//备份文章ID
alter TABLE blog_Article add COLUMN log_ID_backup char(255);
update blog_Article set log_ID_backup = log_ID;
alter TABLE blog_Article add COLUMN log_from char(255);
update blog_Article set log_from = 'lusongsong';
//备份分类ID
alter TABLE blog_Category add COLUMN cate_ID_backup char(255);
update blog_Category set cate_ID_backup = cate_ID;
alter TABLE blog_Category add COLUMN cate_from char(255);
update blog_Category set cate_from = 'lusongsong';
//备份评论ID
alter TABLE blog_Comment add COLUMN comm_ID_backup char(255);
update blog_Comment set comm_ID_backup = comm_ID;
alter TABLE blog_Comment add COLUMN log_ID_backup char(255);
update blog_Comment set log_ID_backup = log_ID;
alter TABLE blog_Comment add COLUMN comm_from char(255);
update blog_Comment set comm_from = 'lusongsong';
//备份Tags ID
alter TABLE blog_Tag add COLUMN tag_ID_backup char(255);
update blog_Tag set tag_ID_backup = tag_ID;
alter TABLE blog_Tag add COLUMN tag_from char(255);
update blog_Tag set tag_from = 'lusongsong';
2、因为文章分类和发布用户数量比较少，手动搞定。需要对增加后的分类做一下修改和替换。
//从站点分类作为新增分类加入
blog
update blog_Article set log_CateID = 8 where log_CateID=1;
update blog_Article set log_CateID = 9 where log_CateID=2;
update blog_Article set log_CateID = 10 where log_CateID=3;
info
update blog_Article set log_CateID = 11 where log_CateID=1;
yulu
update blog_Article set log_CateID = 12 where log_CateID=1;
update blog_Article set log_CateID = 13 where log_CateID=2;
update blog_Article set log_CateID = 14 where log_CateID=3;
update blog_Article set log_CateID = 15 where log_CateID=4;
//从站点文章用户归属处理
update blog_Article set log_AuthorID = 15 where log_AuthorID=2;
update blog_Article set log_AuthorID = 19 where log_AuthorID=3;
update blog_Article set log_AuthorID = 18 where log_AuthorID=4;
update blog_Article set log_AuthorID = 20 where log_AuthorID=5;
update blog_Article set log_AuthorID = 21 where log_AuthorID=6;
update blog_Article set log_AuthorID = 22 where log_AuthorID=7;
3、扩展三个子站数据库中的文章、评论、标签的主ID，防止导入的时候发生覆盖。
update blog_Article set log_ID = log_ID + 3333 //注意要先将主键属性、自动编号去掉。
update blog_Comment set comm_ID2 = comm_ID + 555555 //新建一个字段，评论太多了，本地测试无法修改字段属性了...
update blog_Tag set tag_ID = tag_ID + 222
4、使用navicat将主站先导入mysql。
5、使用插件将对应数据库迁移至zblogphp的表(插件就不说怎么写了哈，主要是写数据库的思路)。插件主要要注意的问题是，几十万评论的操作，要分页处理，不要一口气都转完。本地测试的时候一口气直接转，不是内存爆也不是CPU爆，而是phpcgi直接挂了…………
6、对于三个子站的数据，重复4、5两个步骤，数据转换完成。对于转换后的数据做一下检查，没发现异常就可以了。
7、对于文章Url的处理，包含两个部分：
7.1 首先需要拦截Url输出的接口(目前的ZBLOGPHP 1.4版本还没有，只好先自己写一个)，将输出的格式来源进行修改。
7.2 拦截系统的ViewAuto部分，当url无法匹配系统url规则的时候，把inpurl修改一下再丢给viewpost函数。
至此，数据转换完成，Url保持和原四个站点的Url相同。
总结
很少遇到有机会操作一次数据这么大的站，相对ZBLOG来说一般情况下遇到的都是小规模站点，尤其评论数量近百万的级别更是凤毛麟角。不过这也从侧面反应出一个问题，ZBLOG官方提供的工具包括官方应用中心其他的一些主题、插件，很少有对大数据专门做过优化的，一旦遇上这种数据量很大的问题，就都无法正常工作了。对于具体问题具体分析，掌握主要问题点，一一处理就行了。至于数据库的转换和Url的调整可能每个人都会有不同的方法，技术就是一层窗户纸嘛。
转载请注明：鸟儿博客 » 记录一次比较大型的ZBLOG数据库转换操作
